avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [VOTE] Instrument package into Framework namespace
Date Mon, 24 Feb 2003 15:56:15 GMT

Hi Leo:

See notes in-line...

Leo Sutic wrote:

>  
>
>>From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>>
>>Finally, this is our "last chance" to move the instrument 
>>package into org.apache.avalon.framework space, if we want 
>>to do that. 
>>Last time we talked about it we didn't want to IIRC. Anything 
>>changed? From the perspective of the instrument package, it 
>>makes sense.
>>    
>>
>
>OK, let's run a quick vote for this in order to gauge consensus.
>
>Proposal:
>
> 1. The interfaces from the instrument package should move into the
>    org.apache.avalon.framework namespace.
>  
>
-1

On the question of positioning:

  a) I think that the instrument package belongs at the framework
     "level" as do things like the mata info APIs and lifecycle
     extension mechanisms because they concern the contract between
     the component and the container

  b) I do not think that instrumentation should be included into
     "the" framework level via package name inference.

> 2. The instrument package may be release separately or bundled
>    with the framework jar. We don't decide on this now.
>

I would like to see a release of the instrumentation package once
we have (a) a client and server implementation working in the same
virtual machine independently of a plugin transport, and (b)
separation of transport out of the client package as it stands or
if not possible - moving the instrument client to altrmi.  I would
be positive towards a separately packaged framework "level" release
(where "level" simply addresses the abstract notion of positioning
within the broad spectrum of Avalon content).

I would be opposed to bundling with the framework before some real
consideration of how lifecycle extensions could be apply this
functionality without requiring modification to framework
contracts at this level of granularity.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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


Mime
View raw message