avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Avalon Bundles/Distribution Units
Date Fri, 09 May 2003 18:56:39 GMT
Leo Simons wrote:
> just playing devil's advocate some more.....
> 
> Berin Loritsch wrote:
> 
>>> why not just use .Net?
> 
> 
>  > [we don't know how to program .Net yet; there is no free version of 
> .Net, there is no free .Net support for java; many (free) tools which 
> exist for java do not exist for .Net; we might do better than .Net by 
> taking concepts from other places as well; in conclusion there is a need 
> for a native-java version of this stuff]
> 
> fair enough :D. We should just keep in mind that most of these reasons 
> will likely no longer exist in a few years time. That might affect some 
> decisions :D

We can get this done, or at least workable, in less than "a few year's
time".  That is an important consideration.

The good thing about doing it is it makes it easier to apply the same
principles in new languages that haven't even been invented with.
[Spoiler: I am toying with the idea of writing my own language.  Nothing
concrete yet, though.]

> 
>> One question that also begs to be asked is if this is something that is
>> generic enough to develop in Jakarta Commons, and extend it here.
> 
> 
> well, yes. OTOH, everything in avalon-framework besides the actual 
> XXXble lifecycle interfaces and ServiceManager is generic enough for 
> that as well (ie CascadingException, Context, Configuration, 
> SAXConfigurationBuilder). Where's the potential community for this stuff 
> at?

It is here right now.

> 
> Answering this question is trying to strike the balance between doing an 
> all-encompassing bloatware and an extremely fragmentized 
> doesn't-do-anything 5-levels of abstraction dependency-fragile 
> metametametalayer. You never get it perfectly right :D

:)

I am almost positive that there will be more support for distributable
management than for the Avalon classes that despite their usefulness
in other contexts will forever be bound here.

Also, I agree that we need to strike a balance.  I don't want any
fragile solutions.  I want to keep the dependency list for the bundle
API at a minimum.  We need something that works, and works well.


-- 
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message