--- Sam Ruby <[EMAIL PROTECTED]> wrote:
> Geir Magnusson Jr. wrote:
> >
> > So in a sense, Directory is another library
> project with open
> > rules (like agora). (Not sure if Agora was going
> to be a
> > Library peer in Jakarta-land, or a 'product peer'
> in Library-land.
>
> My biggest concern is that I don't understand the
> relationship between
> Library, Directory, Agora, and Avalon.
>
> Avalon has been in the process of splitting into
> multiple cvs repositories,
> using the naming convention of jakarta-avalon-xxx.
>
> It would be a simple matter to create a
> jakarta-avalon-dbpool.
>
> I'd like to hear consensus with someone representing
> jakarta-avalon (i.e.,
> Peter Donald) before creating another subproject
> with overlapping goals.
Hmm, it would be a damn shame to shoot down the
library project after making so much progress.
Here's my analysis of Avalon vs. Library, with a
little Turbine and Struts sprinkled in for good
measure.
1) Different charters
Avalon's charter is:
The Avalon project is an effort to create,
design, develop and maintain a common
framework for server applications written
using the Java language. This framework will
not be a standalone product, but will allow
existing and yet to be created server
applications to fit into a common platform
and to share code, design and human resources.
Note that Avalon is a _framework_ for servers, which
is clear from the API's many interfaces for request,
responses, pools, properties, etc.
The Library project is quite different. It's goal is
to create components, as self-contained as possible,
that perform (generally speaking) a single useful
function. More specifically, one can implement
Library components _outside_ of the Avalon framework.
(Turbine is a better example of a project where it is
necessary to implement the framework to make use of
the database pools, etc.)
2) Different organization
Our intention with Library is to make each component a
microcosm within the Library subproject. A component
has its own documentation, including FAQ, quick start
guide, etc. It's available as a seperate JAR and has
an explicit list of required/optional dependencies on
other JARs. This should make sharing much easier,
since it will provide a grab-bag of functionality that
can be used without becoming tied to a framework.
Here's a specific example of the dilemna caused by
wrapping all our functionality in big projects. I
have a little JDBC tag library that we're about to
release in Taglibs. However, it's ridiculous for me
to implement my own database pooling for the tag,
because that's way out of scope for the project.
Therefore, I'd like to point to somebody else's
database pool. The question is, whose?
Turbine seems like the wrong choice. Where is the
documentation for the dbPool? Is it adequate on its
own, or will the taglib implementer have to configure
lots of unrelated Turbine functionality as well? I'm
also somewhat uncomfortable pointing people to the
Turbine project, many of whose members are anti-JSP
and therefore anti-Taglib. The last thing I want is
for users to be met with condescension when they ask
the Turbine mailing list for help, which is quite
possible in the current political climate.
Struts is probably more appropriate, but it's still
one big JAR. It's also a "framework for building web
applications" where the inclusion of a database pool
seems, frankly, incidental. It's a good
implementation, but it's a little buried within the
website. In face it's not obvious to the uninitiated
that their database pool even exists.
So, I guess I could go to Avalon and ask them to
implement a database pool, but I'm still faced with
the same old questions. How much of the database pool
is going to be tied up in the Avalon framework? How
self-contained will the documentation and
implementation be? Who's going to write it?
This is a specific example, which to me underscores
the need for a framework-independent repository of
mini-subprojects.
3) Different scope
The Library project should specifically steer clear of
developing grand frameworks. That kind of development
is much more appropriate for full-blown subprojects
like Turbine, Struts, and Avalon.
4) Convergent goals
When possible, other frameworks can plug Library
components into their framework. The Library project
is not intended to be a replacement to Avalong, Struts
or Turbine. Rather it's a place for convergence,
where they can farm out self-contained components and
focus on the means for tying them together.
In some cases, a component may be able to be
completely external to the project. For example,
perhaps Struts does not really need to reference
directly the database pooling code, if it can still
grab connections from a JNDI DataSource or a pooling
Driver. Then we've really reached Nirvana, components
with interfaces so clean that we can literatlly swap
implementations in and out at will.
As long as we focus exclusively on frameworks, I think
it will be very difficult to reach these ends.
- Morgan
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
