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
