directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject [ServerEntry] Serialization
Date Fri, 01 Feb 2008 23:31:25 GMT
Hi,

we are serializing and deserializing Attributes using our own data 
structure, which is efficient, and fast. We have to do the same thing 
for ServerEntry.

The big difference is that we need an access to the Registries in order 
to deserialize the data back to a ServerEntry valid instance. The 
current backend uses JDBM to store the entries, and calls the specific 
serializer/deserializer declared in the JdbmMasterTable instanciation :

    public JdbmMasterTable( RecordManager recMan ) throws NamingException
    {
        super( DBF, recMan, LONG_COMPARATOR, LongSerializer.INSTANCE, 
new AttributesSerializer( ) );
   ...

This AttributesSerializer can be rewritten and moved to handle 
ServerEntry, assuming that :
1) we pass a Registries reference to the JdbmMasterTable constructor
2) the AttributesSerializer class is moved to core-entry
3) we pass the registries to this class :

    public JdbmMasterTable( Registries registries, RecordManager recMan 
) throws NamingException
    {
        super( DBF, recMan, LONG_COMPARATOR, LongSerializer.INSTANCE, 
new AttributesSerializer( registries ) );
    ...

(1), (2) and (3) are easy to manage, but sadly we have a dump command in 
tools which don't use the registries to read infos from the JDBM 
backend, and it won't work anymore if we change the JdbmMaster 
constructor parameters.

However, I would say this is not so important, as no one uses the tools, 
and as we may also load the schema and rebuild the registries into the 
tools.

So, wdyt ? Is it OK to modify the API this way ?

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



Mime
View raw message