At 10:33 1/2/01 -0500, Sam Ruby wrote:
>Peter Donald wrote:
>>
>> I have another theory ;) Reuse occurs vertically not
>> horizontally. For instance Cocoon reuses a lot of Avalon
>> code and when a bit of code reaches a certain "generality"
>> threshold in C2 it is bubbled back into Avalon (ie
>> DataSource pools just did so recently). I assume the same
>> thing occurs with Turbine-Jetspeed (didn't some of
>> Jetspeeds security/user-management bubble back ???).
>
>Good point.
>
>Now for the $50,000 question: Which is "higher": Avalon or Turbine?
depends what you mean by "higher" ;) Going back to original defineition of
Avalon
---
Avalon is;
1. A repository of general utility code (CLI parsing, cascading exceptions,
StringUtils, etc)
2. A repository of patterns and framework code (ie component lifecycle code
and mamanagement code - think loggign, configuring Startable, Stoppable
Suspendable, Reesumable)
3. A set of general utility code based on (2) that offers "doing" code and
extended patterns. (ie object pooling, thread management, classloader
management, policy management, utility classes that "run" components
lifecycle, Container-Component patterns and implementations,
Kernel-Application-Component patterns and implementation).
4. A micro kernel for running services
5. A set of services that are orientated towards server environments (ie
SocketFactories, ConnectionManagers, Schedulers etc)
---
Both Turbine and Avalon could easily share (1) - possibly put it in Apache
Utility Toolkit that JDD proposed ages ago.
Turbine doesn't have much in the way of (2) but this is the only thing that
is stable in Avalon - it's forte and what cocoon/mrymidon use.
Both Turbine and Avalon have (3) but they do different things in different
projects. So relatively little overlap here.
Turbine doesn't need the abstraction of (4) because of the TDK and because
it is assumed one Turbine app per .war.
Turbines (5) partially overlaps with Avalons (3) and Avalons (5).
I don' think that they could share much of (4), (5) and parts of (3) in
short term bu long term it is a possibility.
>I see both as competing for the title of "bottom".
Well Avalon is more generic and you could build a turbine out of Avalon but
not vice versa. Turbines the bottom for web-apps while Avalons the bottom
for component based apps IMHO. Avalon doesn't even try to do half the
things Turbine does well and vice versa.
>It would be a darn shame for each component in the system to continue to
>have its own pool of JDBC connections at runtime.
agreed.
>Struts is a potential customer. There is an interesting dynamic that is
>available for somebody to exploit: the reusable framework with the most
>customers tends to attract more customers.
True but I don't think either Avalon or Turbine are customer directed. They
are built to get a job done and/or because they are kewl ;) If users come
then good as it gives more useful refactoring/perspectives, if not we will
still keep on hacking ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
