-----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:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonMerlinMetaTags
I'm sure Leo was writing down his thoughts so they were not forgotten.
We do need to get back on the stick with the Meta Info stuff. I agree with many of the points. We should separate out that into another discussion.
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?
I am playing around with .NET and C# Avalon Framework. The Meta data in C# is defined by something like this:
type.IsDefined(typeof(MyProj.MyAttributeType), inheritable == true);
Essentially I am talking about something like how our configuration is set up. If anything, we can model Types, Methods (i.e. lifecycle), and Assemblies.
It would be easier to extend the system dynamically by allowing the interface to querry if a type or method has a specific attribute or not. That way things like JMX integration can be treated as an add-in, and the JMX publishing tool will be able to see which methods and types have the attributes set.
It would make it easier to define standards for attributes so that we can have multiple implementations of Management eXtensions if that were necessary.
If we were required to define new MXType objects or MXMethod objects to make things "easier" then we would have a problem with making our container components truly portable.
We could have a simple Attribute interface like this:
public interface Attribute
{
String getName();
String getValue();
String getParameter(String name);
}That would provide the balance between extensibility and usability.
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.
Ok.
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 resolvers.
It was a metaphor. If we want to get away from ServiceSelector (which I believe we do), we need a way of mapping component implementations to each of those short names. For example, in Cocoon there are different types of generators and transformers and serializers. Each of them provides a different way of doing things. A "file" generator is different from a "image-directory" generator, etc.
The sitemap that calls these components up does not know in advance that it will need a "file" and a "image-directory" component.
It is a known requirement for an existing user. We don't want to ignore that use case. We want to provide a better way of handling it, but we don't want to ignore it.
It's not like we can go to the implementation and say that we will always need the "file" and "image-directory" components because those requirements are not known until the component reads the sitemap.xml configuration file. I suppose that we should allow wildcards for declaring that meta info.
I am trying to get a feel for what would be best there.
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
:) Yep.
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.
Let's start with the tools first, and see what evolves from there. We do have existing functionality for instrumentation and management extensions. We can refactor those and where we have common requirements, we can create the Container Management API from that.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
