[Schema refactoring] 3

[Emmanuel Lecharny <el...@apache.org>]

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.

- 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.

- The best possible storage on disk is as LDIF.

- 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.

- 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

- We may want to move the fqcn and bytecode fields of 
LoadableSchemaObjects to extensions (x-fqcn and x-bytecode).

That's pretty much it...

Thanks to Alex and PAM for their ideas.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Schema refactoring] 3

[Alex Karasulu <ak...@gmail.com>]

On Mon, Aug 24, 2009 at 7:08 PM, Emmanuel Lecharny <el...@apache.org>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