Leo Sutic wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
I see something like instrumentation as an "extension" as it provides the classic client contract interface and the container side management aspects.
Agree completely, but where do we put the instrument package then?
So we put it in a completely separate package
(org.apache.excalibur.instrument, or similar), or do we put it into some kind of "extensions endorsed by
Avalon" package org.apache.avalon.extensions.instrument?
I completely agree on the problem - that while instrument has
framework-like interfaces, it isn't part of framework proper - but well, where do we put it?
On package names - the following make sence to me as the
org.apache.avalon.instrument
The current instrument package.
org.apache.avalon.instrument.manager
The current instrument manager package
excluding the two AltRMI classes.org.apache.avalon.instrument.<transport>
Top level package for a particular plug-in
transport solution. For example, you could
imagine "org.apache.avalon.instrument.iiop" or
"org.apache.avalon.instrument.altrmi". Based on my current understanding of the
instrument client package I would place this
under "org.apache.avalon.instrument.altrmi.client".org.apache.avalon.instrument.client
Transport independent presentation API.
On CVS
avalon-sandbox
Because its early, needs more work on doc, more structural separation, and probably one alternative transport to AltRMI - but these things can be addressed in a release early and often pattern. Being in sandbox should not prevent a release - its simply positions the product as new and emerging and not at final release status (at least this is what I would like to see).
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
