Thanks. I think I only looked at the Dev list archives.
Regards, Pierre-Arnaud On 7 juil. 2011, at 12:43, Kiran Ayyagari wrote: > On Thu, Jul 7, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <[email protected]> > wrote: >> On 7 juil. 2011, at 11:37, Kiran Ayyagari wrote: >> >>> On Thu, Jul 7, 2011 at 12:31 PM, Pierre-Arnaud Marcelot <[email protected]> >>> 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" <[email protected]> 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
