db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: simpler api to the Derby store
Date Fri, 04 Jul 2008 14:11:16 GMT
Francois Orsini <francois.orsini@gmail.com> writes:
> I personally believe that even though Derby has a great modular
> architecture, it needs to be more flexible to benefit (and non exclusively)
> other Apache open source projects and at the end benefit the Derby community
> itself (giving back). It would help promoting and increasing adoption and
> contribution.
> Let's say some open source projects are interested in re-using Derby's SQL
> processor and/or Derby's B-Tree implementation, wouldn't it be better to
> allow it (the flexible part) as the base for its architecture is already
> there (the modularity part), or would it better to see other projects
> ripping part of it because there is no easy way to do it and consequently
> not being able to contribute back to Apache Derby? This happens everyday in
> the open source world and very often does materialize as a fork.
> By already having Derby's existing modular architecture and making it a bit
> more flexible would lead to have a microkernel database type of architecture
> and at the end it is a very good thing to have if you can claim this
> (modularity + flexibility)). Combine this with the feature-rich aspect of
> Derby, it opens up many more opportunities for Apache Derby and outside of
> it. Derby's great modular architecture is (unfortunately) not exposed enough
> for developers to benefit from it directly IMHO.

Modular and reusable code is a good thing, I agree. There is already a
number of JIRA issues logged for making modules reusable or
pluggable, for example:

  - DERBY-2164 attempts to make the SQL engine reusable

  - DERBY-3351 is logged to make the storage engine (more) pluggable

  - DERBY-3450 is logged to reduce inter-modular dependencies

Dan has a good point in DERBY-3351 about Derby's storage engine already
being pluggable, because it was designed to be usable in its own right,
although the API could need to be cleaned up and made easier. If someone
wants to do such a cleanup, I think it would be good because

  a) it may make Derby code that accesses the store simpler (easier to
  understand, more maintainable)

  b) it is easier for other projects to use Derby's store directly
  without needing to fork Derby's code base (which potentially
  increases Derby's user base and the chance of getting contributions
  back from those projects)

If we also continue the work on reducing the dependencies between the
modules, it would be easier for others to rip out a module and use it
separately in their product without the modules they don't need. We
could even make this easier by providing build targets that produce
small jar files containing independently reusable modules. These jar
files don't necessarily need to be part of our official releases. I
assume that most users would be fine with using the full derby.jar
although it contains more modules than they strictly need. Just
providing a build option so that users can easily produce smaller/purer
jars from the source release, might be enough to make the users with
special needs happy.

I think all of the above would be valuable improvements to the Derby
code base, and it would also help achieving the goals Rick outlined in
his original post. As far as I can see, there shouldn't be any conflict
between pursuing those goals and the general development of Derby.

> Mike's second point (single b-tree w/ a different codepath) is a clear
> example of what could benefit other projects, not just Derby. We're not even
> talking about some Derby Lite here but more like a flexible architecture
> onto which we can build on top and generate even more adoption, leading to
> more contribution.

I agree, Mike had some very good suggestions that would benefit both the
Derby project and those who for some reason choose to access Derby's
storage engine directly.

Knut Anders

View raw message