Just testing to see if my email provider issues are resolved so that I can participate directly. -bryan

From: jdbm-developer-bounces@lists.sourceforge.net [mailto:jdbm-developer-bounces@lists.sourceforge.net] On Behalf Of Alex Boisvert
Sent: Thursday, October 18, 2007 3:24 PM
To: Bryan Thompson
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] Dependencies on org.CognitiveWeb.extser package

(Forwarding another email from Bryan -alex)

---------- Forwarded message ----------
From: Bryan Thompson <bryan@systap.com >
Date: Oct 18, 2007 10:58 AM
Subject: Reply to the list
To: Alex Boisvert <boisvert@intalio.com>


Sure, I can dual license the code.



I think that it would not be easy to remove the hard dependency.  I have
not looked at the code in a while, but serializers generally require
access to the private fields and are normally inside of the class that
they serialize for that reason, so you could not do a build without the
serialized on hand (unless it is being done by reflection - extser is
not doing reflection, it is a tool for writing efficient serializers).

While you clearly could not build jdbm without the dependency, have you
tried to run it without the dependency?  This was not an integration
goal, but it might work.  If there are problems, you might be able to
address them using reflection to load the dependency only as necessary.


On 10/18/07, Bryan Thompson < bryan@systap.com> wrote:
Sure.  No problem. -bryan

From: jdbm-developer-bounces@lists.sourceforge.net [mailto:jdbm-developer-bounces@lists.sourceforge.net] On Behalf Of Alex Boisvert
Sent: Thursday, October 18, 2007 11:57 AM
To: JDBM Developer listserv
Subject: Re: [Jdbm-developer] Dependencies on org.CognitiveWeb.extser package

Hi Bryan,

If you're willing and able to dual-license the extser package under the current JDBM license, I can easily update the build to download the extser .jar from a Maven2 repo, merge it with JDBM classes and create a unique .jar for JDBM with no external dependencies and a single license.   This would avoid a fork and keep JDBM small and simple -- programmatically _and_ legally.

Kevin, how does that sound?


On 10/18/07, Alex Boisvert <boisvert@intalio.com> wrote:
(Re-posting this on behalf of Bryan since he's having problems with the listserv -- alex)

Hey guys,

The extser package contributes an optional serialization for jdbm that
provides for tight fast serialization for the btree nodes and leaves and
for application data records.

I am willing to contribute the code to JDBM if that is the best thing.

I am still around and able to support the code if something goes wrong -
and you can always fork it if I disappear.

The best reason not to fork the code is because it is used in other
works (mainly my own) that will lose cross-backend support with a code

I am planning to revisit this code over the few months.  I've been
working on a high-concurrency database architecture and I would like to
layer the extser support onto it for high level object model support.
I've also been looking at other options for packed data, in particular
some of the support from mg4j for bit streams, hu-tucker codings, and
various kinds of packed int and long value codings.

Hope you've been well,


On 10/17/07, Alex Boisvert < boisvert@intalio.com> wrote:
Just thinking out loud but what about importing all the classes from the extser package into JDBM's repository?   (We could optionally rename the packages so it looks more coherent).

Separately, there's the issue of having a dependency on code with a different license, which does not make it any easier to "consume" JDBM.


On 10/17/07, Kevin Day < kevin@trumpetinc.com> wrote:
Hi all-
I just got connected up with SourceForge again and grabbed the latest jdbm HEAD.  I'm seeing a dependency injected into a lot of the jdbm classes (BTree, BPage, etc...) for another jar than the basic jdbm jar.
I would like to open up a discussion about this, as I'm a bit concerned about maintainability and keeping the jdbm deployment simple and cohesive.  I know that when we were looking at native hashmap implementations, I actually went so far as to approach the developer of the library to ask that we be able to pull his source into the jdbm package tree.
Is there an alternative approach that we can use that will achieve the result of this external dependency without actually having the dependency?
Even if this was a sub-project of jdbm (as opposed to a completely external project as it is now), I think it would be a good idea to make sure that it was pluggable (i.e. not a requirement for the use of jdbm unless a developer actually wanted the enhanced functionality).
- K