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.
and
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 [EMAIL PROTECTED]
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
