On Mon, Aug 24, 2009 at 7:08 PM, Emmanuel Lecharny <[email protected]>wrote:
> After more thoughts, some new ideas : > > - There is no need to have two classes, one for the SchemaObject, one for > the SchemaObjectDescription. We can simply store the description in the > SchemaObject super class, saving not only one class, but also a > oidToDesctiption() map. > +1 > > - We should keep the user provided elements. Ie, if the user send a NAME in > uper case, like : > ( 1.2.3.4 NAME 'MYATTRIBUTE" ...), we must render it as is. > +1 > > - The best possible storage on disk is as LDIF. > +1 > > - The schema modification on the server must be done as a whole, that means > we must 'encapsulate' a sets of modifications with two extended requests, > one to start the modification, and another one to commit or rollback it. > +1 - LDAP Transactions! > > - We must also allow only one single modification of the schema to occur. > That means we must have a global queue of pending modifications. Once the > first modification is done, we can apply the next one. Of course, this queue > will be emptied after a timeout or if a specific Extented request is sent > Don't understand what you mean here exactly. > > - We may want to move the fqcn and bytecode fields of LoadableSchemaObjects > to extensions (x-fqcn and x-bytecode). > Don't know for sure if that is a good idea. They only apply to our specific SchemaObject types. Alex
