db-general mailing list archives

Peter wrote:
>>>yep. But not really different from how xml <--> jakarta
>>>overlap. Both have web app frameworks both do funky stuff with XML.
I don't see a great deal of conflict between xml and jakarta. I don't see a
sub-sub-project of either sub-project that's painfully out of place where it
is now. There is some overlap, but the partitioning of projects seems pretty
clear. But I do see potentially signficant overlap between db.apache and
both xml.apache and jakarta.apache. Few if any of the projects we've been
considering for db.apache wouldn't fit cleanly into either xml.apache or
jakarta.apache. Many of the projects currently in xml and jakarta fall under
a "data persistence and access" umbrella. (Isn't that precisely what
commons-collections is about? Shouldn't a BTree implement SortedMap?)
Ellis replied:
>>It's a little different because it seems each of the other projects are
>>more technology centric (Jakarta/Java, Perl, PHP, TCL, XML) and not
>>application/mission centric with the major exception of httpd. So 'db' is
>>going to break that mold a bit more and be application specific like
>>httpd?
Geir replied:
>Definitely. That's one of the fundamental principles - as you tend to bring
>a broad mix of things to solve data
>related problems, having a project and community comfortable with that idea
>should work really well.
Maybe. It seems to me that it may be just as likely that the Java parts of
db.apache will have more in common with (and more to the point, share more
code with) jakarta.apache than with anything else in db, and that the XML
parts of db.apache will have more in common with xml.apache than anything
else in db, etc.
To put it another way, it seems to me that the current top-level apache
projects are either built around a specific flagship product (httpd, Perl
[mod_perl], Tcl [mod_tcl]) or around a specific language (Jakarta, XML,
PHP), or started as the former and moved toward the latter (this seems to be
the trend). Adding another top-level project that's really just Java and
XML based stuff (and realistically, that's what we've been talking about)
would seem to add to rather than reduce the confusion (and add some, however
minor, bureaucratic-overhead along the way).
If "community" can be defined solely by having a vaguely common interest,
especially one as broad as "data persistence and access", maybe all we
really need is a discussion forum. It's still not clear to me what we gain
out of creating a container for only-conceptually related projects.
How's this different from creating web-app-frameworks.apache.org out of
cocoon, struts, turbine, and velocity? (And those would likely have more in
common than db.apache projects.)
- Rod
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com