Mailing-List: contact db-help@apache.org; run by ezmlm
Reply-To: rwaldhof@us.britannica.com
From: "Rodney Waldhoff" <rwald@hotmail.com>
To: db@apache.org
Bcc: 
Subject: Re: scope? purpose? rationale?
Date: Fri, 10 May 2002 15:37:18 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <LAW2-F102LUDA1XiHY50000b7f1@hotmail.com>

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