directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ServerEntry] Serialization
Date Sat, 02 Feb 2008 00:59:28 GMT
Hi Emmanuel,

On Feb 1, 2008 6:31 PM, Emmanuel Lecharny <> wrote:

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

    I have re-factored this class heavily in my private branch and it has
been generified btw.  This is kind of cool because it means we can reuse
this for storing and indexing any kind of objects, not just entries.
Anyways more points below about all this.  But please note that all changes
here I'd like to do in the private branch so we don't have a serious
conflict nightmare.

What do you think about this alternative idea?  We extend a JDBM Serializer
which can serialize and deserialize.  Take a look at it, it's part of the
JDBM API.  The subtype can be ServerEntrySerializer and we implement the
serialize and deserialize methods.  Whatever creates this
ServerEntrySerializer can stuff it with the registries so we don't have to
have Registries exposed to these classes or to this package.

Another thing we could do is create our own JDBM neutral/independent
interface with these serialize and deserialize methods: call it Marshaller.
We can create an implementation that specifically handles the
[de]serialization of ServerEntry objects.  And we can make this
parameterized (generified).  Then we can mandate that the MasterTable<E>
class take a Marshaller<E> in it's constructor.  The constructor can then
wrap this up in a Serializer inner class specifically suited for JDBM.  We
can make sure the reference to the Marshaller is a transient handle that can
be set when we create a MasterTable in case JDBM does something funny and
desides to store this thing into it's db files.

Now this Marshaller can be used anywhere we need to serialize the entry,
over the network with Mitosis or to disk with the JDBM and potentially other
partition implementations.


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

I think the proposed mechanism will create too much interdependency
especially between modules.


View raw message