db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Footprint - Was Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Date Tue, 28 Jun 2005 17:15:44 GMT
David Van Couvering wrote:

> Hi, Dan.  Can you clarify me the motivation behind keeping the footprint
> down?  Are we targeting PDAs?  What kind of platforms are you
> envisioning for Derby that require a minimal footprint?  I agree that in
> general smaller is better, but for instance is smaller a priority over
> readability/maintainability (for example, building an architecture with
> fewer classes doing more things rather than more classes with
> well-defined responsibilities)?  Is it a priority over performance?  Is
> it a priority over more advanced features such as replication, XML
> support, additional SQL features, etc.?  What's the order of precedence
> for these types of key qualities of Derby, in your view?

I think it's a balance of qualities, footprint, features, ease of use,
performance. Footprint and features are very concrete things people
measure databases with, thus if Derby has a footprint that is ten times
larger than other comparable technologies it will be rejected at an
early stage. For features I think there are core features that need to
be part of the technology and others that should be optional for people
to choose. Thus, I believe, XML support will be an essential part of
every database thus building in it is fine, replication on the other
hand should be optional so that people aren't forced to pay the overhead.

I do believe there is a good fit for Derby on embedded servers, set-top
boxes, cash registers, gaming machines where footprint is a concern.
Over time with Cloudscape we saw (and continue to see) people want all
the SQL features, a JDBC engine that just does basic operations doesn't
interest folks. People would love Cloudscape's functionality in 100k.

It's also, to me, an interesting challenge, provide the value of the
functionality within a small footprint as possible, without sacrificing
performance, quality and ease of use.

And finally, this is open source, Apache can provide basic packaging of
the software, anyone else can package it as they want. If someone
believes they can provide value by shipping a J2ME specific Derby
engine, that's great, or look at Gluecode, their value was a complete
J2EE stack with Derby. The Derby project has to provide the core
technology and some reasonable packaging, encourage others to build
projects or products based upon Derby.


View raw message