The Hermit Hacker wrote:
>
> On Mon, 15 May 2000, Peter Eisentraut wrote:
>
> > On Mon, 15 May 2000, The Hermit Hacker wrote:
> >
> > > Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
> > > uses ours, but if someone wants to do the db code, it could plug-n-play?
> >
> > But wasn't the main reason Michael Olson gave that a lot of code could be
> > removed because Berkeley DB does it for you? But with that switch we'd end
> > up with more code, not less.
>
> right, and my point was that, up until now, we've worked at making sure
> that the whole thing is self-contained ... as soon as we throw in a
> third-party piece of software that is *efffectively* our guts, we now
> throw in a new point of failure for the end users ... what happens if, a
> year down the road, SleepyCat decides that v4.0 falls undera new license
> that negates our ability to use it? we've just drop'd all our guts in
> favor of theirs and now what?
There could be some ways to get a twisted license (like Medusa used in
Zope)
where the Berkeley DB used in PostgreSQL is free but used without
postgres
is still under the original Sleepycat terms.
That arrangement seems to work quite nicely with Zope.
I still don't see how we could replace some part of storage manager and
access methods guts with Berkeley DB and still keep the extended
features
like R-trees and MVCC (and sure there are others), and integrate two
types
of transaction management on top of them.
> I'm not saying that using some of SleepyCat's stuff for backend is a bad
> idea, but I'm saying that we shouldn't be relying on it ... add on, yes ...
But what would the idea of such add-on be ?
Does it offer real advantages over our current scheme ?
If so, is the integrating effort significantly less than fixing what we
have ?
BTW, is there a general-purpose optimisation library available that we
could use instead of our current one ? ;)
-----------------
Hannu
