Re: [Jdbm-general] extensible serializer

[Cees de G. <cde...@gm...>]

If no-one objects, i'll try to bake a 1.0rc1 today that has:
- CVS HEAD
- The Big ApacheDS Patch[tm] :-)

Another issue is package naming - we use "jdbm." atm but we need a
real domain name to release on ibiblio. So that either means we shove
it under the Apache umbrella fast, or we get our own domain name
(vastly in favor of the first option, I'm already the proud owner of
more domain names than I want).


On Tue, Jun 10, 2008 at 9:24 PM, Alex Boisvert <boi...@in...> wrote:
> Ok with me.
>
> alex
>
> On Tue, Jun 10, 2008 at 11:34 AM, Cees de Groot <cde...@gm...> wrote:
>>
>> If the license issue is sorted, I'm more than happy to keep it in. The
>> original JDBM interfaces are still there, and I'll just move it to
>> jdbm.extser or similar.
>>
>> Any objections? I mean, upside, no license problems, and through code
>> inclusion no dependencies issues. Sounds like ok to me...
>>
>> On Tue, Jun 10, 2008 at 7:11 PM, Bryan Thompson <br...@sy...> wrote:
>> > Interesting.
>> >
>> > I had to do some significant work in order to get jdbm to persist the
>> > serializer state.  I would suggest that you look at the code more
>> > carefully
>> > rather than just rolling it back.  Assuming that xstream uses a stateful
>> > serializer, you are going to want to preserve the integration points.
>> >
>> > By "stateful" serializer, I mean one that maintains persistent state NOT
>> > recorded in the individual serialized records.  extser factors out what
>> > serializers are declared, the class ids (int's) assigned to each class
>> > for
>> > which there is a registered serializer, and the corresponding serializer
>> > version(s) and puts that all into a persistent record accessed off of
>> > one of
>> > the named roots for the store.  This makes it extremely compact when
>> > serializing object graphs.  The shared state is all factored out.  In
>> > order
>> > to support that I had to put in a bunch of hooks that you will want to
>> > keep
>> > around.
>> >
>> > Another issue with versioned serializers is that they basically have to
>> > be
>> > inner classes in order to access the various fields (unless you want the
>> > overhead of reflection during serialization!).  One of the changes that
>> > I
>> > introduced with the extser integration was transparently versioning for
>> > the
>> > btree nodes and leaves for stores that choose to enable extser.  If that
>> > forward versioning is important then you are going to wind up with
>> > something that's tightly coupled regardless.
>> >
>> > If the broader issue is the dependency, then Cees already imported
>> > extser
>> > and I "authorize" its relicensing under the license for the jdbm
>> > project.
>> >
>> > -bryan
>> >
>> > ________________________________
>> > From: jdb...@li...
>> > [mailto:jdb...@li...] On Behalf Of Mark
>> > Proctor
>> > Sent: Tuesday, June 10, 2008 12:54 PM
>> > To: Bryan Thompson
>> > Cc: 'Cees de Groot'; jdb...@li...;
>> > cow...@ya...
>> > Subject: Re: [Jdbm-general] extensible serializer
>> >
>> > Bryan Thompson wrote:
>> >
>> > Well, easy come, easy go - but you might want to see who's using it
>> > before
>> > you drop it out.
>> >
>> > There is zero overhead when extser is not enabled.
>> >
>> > it's not so much the overhead, its the extra dependency. Even if you
>> > don't
>> > use it you are forced to include it, because Serialiser extends it. So
>> > if we
>> > are to use it, it needs to be "plugged" in, so that it's optional.
>> >
>> > The LGPL is a wierd issue, basically Apache takes a stand against LGPL
>> > and
>> > will not allow any of it's projects to depend on an LGPL dependency.
>> > This
>> > would force Apache DS to have to fork JDBM to maintain a version without
>> > that LGPL dependency. It's not that they think that LGPL is causing any
>> > wierd violation, they just don't like some of the ambiguity, and thus
>> > fall
>> > on the side of caution.
>> >
>> >
>> > -b
>> >
>> > ________________________________
>> > From: jdb...@li...
>> > [mailto:jdb...@li...] On Behalf Of Mark
>> > Proctor
>> > Sent: Monday, June 09, 2008 10:58 AM
>> > To: Cees de Groot
>> > Cc: jdb...@li...; cow...@ya...
>> > Subject: Re: [Jdbm-general] extensible serializer
>> >
>> > Cees de Groot wrote:
>> >
>> > On Mon, Jun 9, 2008 at 4:24 PM, Cees de Groot <cde...@gm...>
>> > wrote:
>> >
>> >
>> > I grabbed the extensible serializer source code and added it to the
>> > source tree - the original project doesn't seem to exist anymore so I
>> > thought this was the quickest way to get rid of a binary-only
>> > dependency.
>> >
>> >
>> > Great, I'l update and look over it. For me I just want JDBM to write my
>> > byte[], I don't want it to go anywhere near a serialistion method call,
>> > I'm
>> > currently just trying to find out if that is possible.
>> >
>> > On second thought, I agree it's not good to have JDBM depend on a
>> > single serializer. So I'm removing the dependency (rolling back to the
>> > pre-extser tag in CVS and checking what happened after that)
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> "Human beings make life so interesting. Do you know, that in a
>> universe so full of wonders, they have managed to invent boredom. " -
>> Death, in "The Hogfather"
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Jdbm-general mailing list
>> Jdb...@li...
>> https://lists.sourceforge.net/lists/listinfo/jdbm-general
>
>



-- 
"Human beings make life so interesting. Do you know, that in a
universe so full of wonders, they have managed to invent boredom. " -
Death, in "The Hogfather"