Thread: Re: Proposal: replace no-overwrite with Berkeley DB
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? 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 ... exclusive, no ...
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
> 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? > > 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 > ... exclusive, no ... We could get perpetual rights to the code as integrated into our code. Also, if they change something, we could always take it as our own and keep it working for us. I think we would need something like that. It sort of goes to how open we are. Someone can always take PostgreSQL and create a branch if we do a terrible job. We would need that assurance of the Sleepycat DB. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> >We could get perpetual rights to the code as integrated into our code. >Also, if they change something, we could always take it as our own and >keep it working for us. I think we would need something like that. > One of the often-stated virtues of PGSQL is that it is easy for a company to take the source and go commercial. If you start integrating 'special license greements' into the development, then that advantage is severly reduced. A commercial operator has to form an agreement with sleepycat or rewrite the storage manager. Unless sleepycat grant a completely open license to PGSQL and all it's commercial descendants in perpetuity, it seems you may be removing one of the seeling points of PGSQL. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
> > > >We could get perpetual rights to the code as integrated into our code. > >Also, if they change something, we could always take it as our own and > >keep it working for us. I think we would need something like that. > > > > One of the often-stated virtues of PGSQL is that it is easy for a company > to take the source and go commercial. If you start integrating 'special > license greements' into the development, then that advantage is severly > reduced. > > A commercial operator has to form an agreement with sleepycat or rewrite > the storage manager. Unless sleepycat grant a completely open license to > PGSQL and all it's commercial descendants in perpetuity, it seems you may > be removing one of the seeling points of PGSQL. Yes, something like this would be required. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026