db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@adeptra.com>
Subject Re: scope? purpose? rationale?
Date Fri, 10 May 2002 22:03:24 GMT
DISCLAIMER : the term 'db' is only a working title and doesn't accurately
represent the scope of the project discussed.

On 5/10/02 11:37 AM, "Rodney Waldhoff" <rwald@hotmail.com> wrote:

> 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 conflict either.  It's not about avoiding conflict, its about
bringing projects together and trying to get a community of like-minded
people working together.

> 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.

I guess.  Seems like Coccon could wander over to Jakarta, and some of the
stuff in commons (digester, the xpath stuff) really belong in XML land.
However, it's clear that there is common interest between the two groups -
the XML people want to do something useful with all those pointy brackets,
and the jakarta people have pointy brackets they want to do something useful
with  :)

>  But I do see potentially signficant overlap between db.apache and
> both xml.apache and jakarta.apache.

And that is *good*, especially if dependencies between things in 'db' and
xml and jakarta create real crosstalk between the three communities.

> Few if any of the projects we've been
> considering for db.apache wouldn't fit cleanly into either xml.apache or
> jakarta.apache. 

Hm.  I agree, sort of, especially since jakarta is becoming  scope==Java.
Also, the notion of 'server side java' is expanding - so even if we weren't
getting sloppy with scope in Jakarta, the scope is naturally growing.

It's like having a 'programming' interest group - there are too many
subcommunities - the basis of commonality is just to basic.

> 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?)

When you put it that way, httpd and modem ROMs are about data access, and
disk device drivers are about data persistence, but neither belong under
commons-collections IMO.

I think the difference has to do with application scope.

> 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.

I think you have to ask what 'in common' means.  Language?  I don't think
that's relevant. Most  things in xml.apache.org were written in Java.
Cocoon is written in Java, and is a server-side application framework right?
Why is it in xml.apache.org?  Could it be because there are like-minded
people there that are working on problems involving XML?  I think so but am
not sure.

> 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), 

But building a top level project around language alone is futile - XML isn't
a language, but a spec.  Most of the code in xml.apache.org is in Java.  So
why the difference?  Could it be application domain?

> 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)

Right - but reducing it to it's base components is missing the point I'm
trying to make.  The important thing is application scope.  As I understand
it, Jakarta started around a then exciting new technology called 'Java
servlets'.  Would you say that was pointless as it's just another way of
getting data via the web, so glom it into httpd?  I don't think so....

> would seem to add to rather than reduce the confusion (and add some, however
> minor, bureaucratic-overhead along the way).

Not sure what the overhead would be.  If you want to be a committer for a
Jakarta project, you have to contribute to the community and be offered the
status by the community.  In "db" I can't see why it would be different.
All stuff is hosted on the same cvs server, so that's not a problem.  You
could use your current apache committer id and such if you became a
committer in a new ""db" subproject, so that's not a problem.  Where's the
> 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.

I don't quite understand your position.  On one hand, broad interests like
"data persistence and access" is too broad of an application vertical to
create a community, and on the other, something like "software written in
Java" or "data formatted with pointy brackets" is ok?

(Yes, I'm greatly over-generalizing the 'pointy brackets' thing about

> 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.)

That would actually make sense and be useful, I think, if all wanted to work

(Of course, I wouldn't know if Velocity belongs there, as it's not a webapp
framework but a general template engine that can be used by webapp
frameworks.  Torque uses Velocity too.  So does Poseidon-UML.  So does...
It might be better to group Velocity with ant, regexp and oro.  However...

Geir Magnusson Jr.
Research & Development, Adeptra Inc.

View raw message