river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John McClain - Sun Microsystems, Inc." <John.McCl...@Sun.COM>
Subject Re: a potential "AR1" release
Date Tue, 04 Sep 2007 15:22:35 GMT
Mark Brouwer wrote:
> I see no problem though in e.g. providing the interface to Berkeley DB
> in the same way as it was/is done for PSE but I would be against
> shipping Berkely DB (assuming it was/is possible), but there are also
> other decent performing routes possible based on compatible licenses.


> Mark Brouwer wrote:
>> the principals contained in the ALv2 or what is written as the guiding
>> principles here: http://people.apache.org/~rubys/3party.html.
> Reading further it is even explicitly mentioned the Sleepycat license is
> not allowed for inclusion in an ASF product, see
> http://people.apache.org/~rubys/3party.html#category-x 

Thanks for the leg work, I guess Sleepycat isn't an option.

FWIW, left to my own judgment I would make the performance improvements 
to snapstore first (http://issues.apache.org/jira/browse/RIVER-128 and
http://issues.apache.org/jira/browse/RIVER-171, they are against 
logstore, but apply to snapstore too). This would give us a performance 
base line that we could measure new store designs against.

The easiest way to address RIVER-128 is to break the log format, given 
that changing all the package names is also going to break the log 
format doing RIVER-128 before the first real release has some appeal.

John McClain					john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

View raw message