From: Kevin D. <ke...@tr...> - 2008-11-19 19:45:35
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV>Sorry to hear that - certainly not my intent. The reason that I'm not pushing 2.0 is that I have 6 commercial products that I actively develop, and I don't actually have a need for full blown transactional management in an embedded database for any of those projects. I *did* have the need for an efficient row level compression mechanism, which is why I developed it and added it to the system in a way that didn't impact other areas of the code base, which is why I was added to the development team. Right now, I have a need for heavy PDF processing, so the time that I do have to devot to open source projects is going to contributions to the iText project. These things move in cycles, and it would be great to have someone on board with an active interest in moving 2.0 forward.</DIV> <DIV> </DIV> <DIV>I think that the challenge you may be running into is that the change you are proposing is a good one (I don't think anyone will disagree with that) - but it impacts almost the entire code base. That means that having robust and reliable testing is critical to ensure that changes made don't break existing users of the library. This is made doubly difficult because it is hard to unit test concurrency. But by the same token, that is exactly why having the tests is so critically important. Is the objection that you have to writing the tests? If so, then I think you will run into some problems with this particular team of developers - we write tests first, then we write code.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Anyway, I hope that the two hours I just spent performing a code review of your submission results in some good ideas for you.</DIV> <DIV> </DIV> <DIV>I'm all for lowering barriers to entry, but I will say that there are a *lot* of very complicated technical decisions that have to be made to ensure that the next design is solid. You can take a look at the archives of the developer listserv to get a feel for the issues that are being discussed, and if you have opinions on great ways to implement these kinds of changes, post them and get added to the team!</DIV> <DIV> </DIV> <DIV>- K</DIV> <DIV> </DIV></FONT> <DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma"> <DIV>----------------------- <B>Original Message</B> -----------------------</DIV> <DIV> </DIV> <DIV><B>From:</B> "Elias Ross" <A href="mailto:ge...@no..."><FONT color=#0000ff><ge...@no...></FONT></A></DIV> <DIV><B>To:</B> "Kevin Day" <A href="mailto:ke...@tr..."><FONT color=#0000ff><ke...@tr...></FONT></A></DIV> <DIV><B>Cc:</B> JDBM Developer listserv <A href="mailto:jdb...@li..."><FONT color=#0000ff><jdb...@li...></FONT></A></DIV> <DIV><B>Date:</B> Wed, 19 Nov 2008 10:24:20 -0800</DIV> <DIV><B>Subject: <U>Re: [Jdbm-developer] "Fine grained" Read/Write locking</U></B></DIV> <DIV> </DIV></DIV><FONT face=Tahoma size=2> <DIV>On Tue, Nov 18, 2008 at 2:51 PM, Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><ke...@tr...></FONT></A> wrote:<BR><BR>> At this point, the project is involved in incremental improvement up to the<BR>> point that a major rewrite can be considered (most likely with a change in<BR>> API). Targets for the major rewrite (when we volunteers get enough time to<BR>> work on it) are focused on adding multi-transaction and roll-back behavior -<BR>> as well as addressing the concurrency issues with the current architecture.<BR><BR>Kevin, an interesting phenomenon I've observed is talented people<BR>never have enough time to work on something unless the barrier to<BR>entry is lowered.<BR><BR>I'm guessing (not certain) that simply creating a 2.0 codestream and<BR>opening yourselves up for business will generate more progress than<BR>waiting for people to "free up." I'm not sure who's the "leader" of<BR>the JDBM group, but why not you lead, Kevin?<BR><BR>Personally, you've done much to discourage me. Honestly, it'd be less<BR>effort if I just forked JDBM and did with it what I wanted.<BR><BR>-------------------------------------------------------------------------<BR>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<BR>Build the coolest Linux based applications with Moblin SDK & win great prizes<BR>Grand prize is a trip for two to an Open Source event anywhere in the world<BR><A href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"><FONT color=#0000ff>http://moblin-contest.org/redirect.php?banner_id=100&url=/</FONT></A><BR>_______________________________________________<BR>Jdbm-developer mailing list<BR><A href="mailto:Jdb...@li..."><FONT color=#0000ff>Jdb...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/jdbm-developer"><FONT color=#0000ff>https://lists.sourceforge.net/lis ts/listinfo/jdbm-developer</FONT></A><BR><BR></DIV></FONT></BODY></HTML> |