Peter, I don't know if you know this, but you are also CC'ing the same
address in your replies. You might not want to do that. :-)
Date: Thu, 01 Feb 2001 15:10:51 +1100
To: [EMAIL PROTECTED]
From: Peter Donald <[EMAIL PROTECTED]>
Subject: Re: What is Avalon?
Cc: <[EMAIL PROTECTED]>
on 1/31/01 8:10 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> Similar thou not 100% the same. Turbine more follows the JNDI/J2EE
> application level model. (ie grab the service from a central
> application-wide directory). Avalon is more focused on per component level.
> (ie components are mapped from global area to a local per component area
> which the component accesses). But other than that they are very similar ;)
Correct. Our goal was to provide a singleton manager to the currently
running Turbine application in a particular context. This allowed for an
easy implementation of a Global Cache Service...
>> Database Connection Pooling
>> Schedulers (ie: Java based cron with a RDBM's backend)
>
> Theres possibly even more overlap than you think ;) We have
> Initializable/Disposable interface which IIRC are similar to Turbines
> interfaces. We also have the next-evolutions of many of original jserv
> interfaces/classes (Configuration etc).
Yep, we have those as well. :-)
> There is also similarities between
> many of the ideas except Avalon is a lil more general (ie we use Context a
> generalisation of RunData etc).
RunData is an object that is over 3 years old now...no really, I'm serious.
:-) I probably would have done it differently today. :-)
> There is other remarkable simularities and if you were to read the Avalon
> archives for last few weeks I have been advocating changes that would
> enable a TurbineKernel and TurbineApplication objects (so you could load
> independent apps into one turbine instance safely).
Hmm...I'm not sure that is really needed, but cool anyway.
> So you could say I
> think in a turbine-esqu way ;)
That makes me happy. :-)
> yer thats where the problem is. The only production level stuff is either
> solely based on the "framework" part or using ancient versions of the kernel.
Part of Sam's complaint. :-)
> yep thats an alternative. It was just that Sam complained about this a
> while back with respect to tinderbox and nesting of projects.
>
> It could also cause more issues because we could have cornerstone relying
> on version 3.1.1 of avalon, 3.2a of phoenix and actually being 3.2beta
> itself. The only way we could fix this is to store versioned jars in CVS
> (no biggue for me) and put in gratutous documentation stating that you can
> not copy /avalon/dist/lib/avalonapi.jar to /phoenix/lib/avalonapi.jar and
> expect it to work as they are on completely different release schedules.
> This could add a fair bit of confusion during building and attracting more
> developers.
I hear you.
> That would be fine if they were different versions of the one product.
> However they are different products that just happen to be part of the same
> project ;) each having different release schedules. I guess it would be
> similar to some think like
>
> jakarta-avalon (or perhaps jakarta-framework) == c std library
> jakarta-phoenix == linux kernel
> jakarta-cornerstone == linux kernel modules
Ok, then in this case, I would prefer it to be:
jakarta-avalon
jakarta-avalon-phoenix
jakarta-avalon-cornerstone
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
