Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Reply-To: <msegel@segel.com>
From: <derby@segel.com>
Sender: "Michael Segel" <msegel@segel.com>
To: "'Derby Discussion'" <derby-user@db.apache.org>
Subject: RE: Future of Derby (was Re: Can derby instances be clustered ?)
Date: Thu, 27 Apr 2006 06:50:48 -0500
Organization: MSCC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcZpU/PKQeY+9ZmzRKqducHeHgDZOAAmB11A
In-Reply-To: <444FA7FD.70409@sun.com>
Message-Id: <20060427115324.22C35490D1@dbrack01.segel.com>


> -----Original Message-----
> From: David.Vancouvering@Sun.COM [mailto:David.Vancouvering@Sun.COM]
> Sent: Wednesday, April 26, 2006 12:04 PM
> To: Derby Discussion
> Subject: Future of Derby (was Re: Can derby instances be clustered ?)
> 
> I think this is a great question, Michael.  Derby clearly differentiates
> today in its nature as lightweight, embeddable, easy to use and secure,
> while still being fully functional.
> 
[mjs] Yes. And lets consider this the starting point.
Today Derby is a light weight general purpose RDBMS.

> But I think we're going to see more and more "big" users wanting "big"
> features from it.  Do we Just Say No?  Is there a way to architect Derby
> to handle larger deployments while still staying true to its roots?
> 
[mjs] Yes. And that's the crux of the problem.
Looking at Cloudscape's heritage users, Derby is an embedded DB. You
increase the size of the footprint, you increase the "costs" of
implementation, making it less desirable. 

> At a high level one could argue that features like replication and
> clustering, with the right level of effort and intention, can be made
> "pluggable", and can be "unplugged" using the module architecture so
> these features are not available and the classes are not even in the
> footprint when you want to use Derby as a lightweight database.
> 
[mjs] 
Exactly. A pluggable architecture is a potential. You would then have to
create a developer's workbench or tool that would allow you to create
customized "deployment" versions of the engine. (Why package a class if its
not being used?)

So the feasibility of such a design has potential. However, who is going to
design and implement it?

> If anyone *were* to propose introducing such high-end features, the
> community would, I would hope, look long and hard at how its built to
> try to ensure that the impact on the "core" is minimal.
> 
> David
> 
[mjs] 
Ok. 
It would realistically mean a hard core review and probably a major rewrite
of a lot of the engine. Call it Derby 2.0. The nice thing though is that
with a little bit of effort, you could probably reuse a lot of the existing
components of derby. (And actually a good excuse to go module by module and
fix a lot of the "issues" documented in jira.)

Is Sun or IBM willing to step up to the plate?
(That's a rhetorical question, BTW) Not that I'm picking on Sun or IBM, but
they do have a vested interest in controlling the future of Derby. And they
have the "deep" pockets to pay for this sort of work. 

The offshoot of this is that such a framework design could be built in to
DB2 or IDS as well. (And there are some advantages to this...) 

In order to be successful, there would have to be a core group of
"volunteers" willing to step up to the plate and run a re-architect project.
Now who has time to dedicate enough of their gray matter? (Hence the call to
Schwartz and Mills to step up to the plate....)

> P.S. Michael: why do you always say "hey, what do I know?"  We should
> call you Michael Wadduino Segel :)
> 
[mjs] 
Uhm no. Just call me Gumby. ;-)
Its really an old inside joke that goes back to '97 - '00 time frame.
After Phil screwed the pooch, Informix was lead by a couple of brain dead
CEOs. (Finocchio and Dexmier) But that's another story... ;-)