On Wed, 28 Feb 2001, Morgan Delagrange wrote:
...snipped here to prevent filling up your mailbox with duplicate stuff...
>
> 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.
I understand it this way too. A not-totally related point is, if it takes
more than a few of us more than a few days of digging to really nail down
exactly what Avalon is, would it be reasonable to expect a first time
visitor to Avalon to understand it as a place to get individual
components?
>
> 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.
>
And along those lines, the components are inherently neutral in terms of
being tied to one of many different versions of the "one and only way to
do it". But I guess that is just restating what you say below :)
> 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.
>
+1 for nirvana!
> 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/
>
