directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [Shared] DN value for schema modification entry
Date Thu, 07 Jul 2011 10:43:56 GMT
On Thu, Jul 7, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
> On 7 juil. 2011, at 11:37, Kiran Ayyagari wrote:
>
>> On Thu, Jul 7, 2011 at 12:31 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
>>> Is this modifications storing feature even working?
>>> From what I've seen in the code, it looks more like a placeholder and the
>>> feature is still waiting for implementation...
>>> I couldn't find where Studio was depending on it, Kiran. Can you give me
>>> some pointers, please?
>> I remember Seelmann mentioning on ML that studio depends on this DN to
>> update the cached schema, but this
>> feature is not working due to an issue on server ( I believe it was
>> working at one point of time but was broken later)
>
> AFAIR, the cached schema of a connection in the LDAP Browser plugin is read from the
DN provided via the 'subschemaSubentry' AT of the RootDSE entry.
> I looked in my ML mails archive but couldn't find a related discussion about the usage
of "cn=schemaModifications,ou=schema" in that area.
>
this has some details about it http://markmail.org/thread/tx37zeusdtye3nbo
> Anyways, it might be a good time to do this as you mentioned.
> IMO, it shouldn't have a huge impact on Studio.
>
yeah am gonna fix this
> Regards,
> Pierre-Arnaud
>
>
>>
>>> Thanks,
>>> Pierre-Arnaud
>>>
>>> On 6 juil. 2011, at 23:15, Kiran Ayyagari wrote:
>>>
>>> had thought about this earlier but studio depends on this DN so didn't do
>>> that, now is perhaps the right time to do it for version 2.0 of both
>>>
>>> On 07-Jul-2011 12:34 AM, "Emmanuel Lecharny" <elecharny@gmail.com> wrote:
>>>
>>> On 7/6/11 7:49 PM, Kiran Ayyagari wrote:
>>>>
>>>> hello guys,
>>>>
>>>>   We currently have an entry with DN cn...
>>>
>>> IMO, the best would be to have a special AT injected into the ou=schema
>>> entry, instead of having a dedicated entry to store the very same
>>> information. It would solve the issue quite efficientely.
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Kiran Ayyagari
>
>



-- 
Kiran Ayyagari

Mime
View raw message