From: Bryan T. <br...@sy...> - 2007-10-19 12:06:11
|
Just testing to see if my email provider issues are resolved so that I can participate directly. -bryan _____ From: jdb...@li... [mailto:jdb...@li...] 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 <br...@sy... <mailto:br...@sy...> > Date: Oct 18, 2007 10:58 AM Subject: Reply to the list To: Alex Boisvert <boi...@in...> Alex, Sure, I can dual license the code. -bryan Kevin, 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. -bryan On 10/18/07, Bryan Thompson < br...@sy... <mailto:br...@sy...> > wrote: Sure. No problem. -bryan _____ From: jdb...@li... [mailto:jdb...@li...] 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? alex On 10/18/07, Alex Boisvert <boi...@in...> 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 fork. 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, -bryan On 10/17/07, Alex Boisvert < <mailto:boi...@in...> boi...@in...> 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. alex On 10/17/07, Kevin Day < <mailto:ke...@tr...> ke...@tr...> 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). thanks, - K |