avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [RT] Container Components
Date Fri, 27 Jun 2003 18:03:27 GMT

> -----Original Message-----
> I would like to work with a basic extensible meta info library that is
> lightweight, well-tested, and can be used in all containers.  We need
> to work with the AMTAGS proposal, and fill in any holes.

I think the best idea would be to work with the existing meta package under
the sandbox and somehow combine that with the AMTAGS proposal.

Leo Simons sent out an email a while back and made a wiki entry on some
concerns with the existing meta package and I never saw much discussion on
it.  It was quite a critical review, but it might be a good place to start
in terms of merging AMTAGS and the meta package:


> IMO we should work with a Queryable interface as opposed to an object
> model based one.  While an object model provides a certain ease of use,
> it is not as extensible.  I am open to discussion on the matter, and
> hopefully there will be reams of emails when I get back....

I'm not sure I'm following your ideas on a queryable interface.  Perhaps a
simple example would help?

> As to the Assembly information what do we need beyond the simple component
> mapping?  What do we want to formally represent?

Merlin's Appliance interface provides a good starting point I think.

> Also, how do we deal with components that have a lookup something like
> URL protocol resolution (i.e. "http" pulls up the HTTP protocol handling
> component and "ftp" pulls up the FTP protocol handling component)?

Shouldn't we be able to build off of the source resolver for this?  Perhaps
we need an Avalon naming (or lookup?) package which handles URI's and URL's
better. This could then plug into source factories or other naming

> How do we come to a middle ground with Phoenix, Merlin, and Fortress?

Minimally the first steps would be to:

1. Release meta package standard which includes standard AMTAGS
2. Release standard assembly package

I think the container components mentioned thus far best fit within the
scope of assembly adaptors or extensions.  Perhaps there would be the need
for a third step:

3. "Container Management API"

which would handle base extensions like instrumentation, management
extensions and directory (lookup) extensions.  Maybe this is better called a
Kernel API taking the idea of a Kernel from merlin.  This is the point where
I'm not sure what would be best.  But minimally, the assembly and meta
packages would be needed first.  Then we at least have something to work
with and towards.


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

View raw message