Peter:
Thanks for you reply - see notes in line:
Peter Royal wrote: > On Saturday, March 22, 2003, at 12:33 PM, Stephen McConnell wrote: > >> I would argue that the process would be more constructive if we >> made the assumption that a certain set of tags exist - and from >> that assumption, work on ensuing that the respective >> interpretation of those tags by different tools and resulting >> meta-info are consistent. > > > The primary stickler seems to be over the lifestyle tag being in the > @avalon namespace. I see Pete's argument, only things that *ALL* > containers support go into the @avalon namespace.
In practice all of the containers - Fortress, Merlin and Phoenix make assumptions about lifestyle. In the case of Merlin and Fortress there are mechanisms to support different assumptions based on information supplied by a compoent type (whether declared in a marker interface of via formal meta-info descriptors).
If component assumes a "transient" lifestyle - it will not function properly within Phoenix. To overcome this, Phoenix needs an ability to recognize that a particular component type requires a particular lifestyle strategy (independently of ability to support it). The recognition of @avalon.lifestyle by Phoenix is a first step by dealing with recognition.
This isn't about "stuff that all containers support".
It's about stuff that all containers can recognize. This is important point.
> As a compromise, ow about we establish an @avalon-x namespace that > holds items that, in the future, may be promoted to the @avalon > namespace?
The downside of this approach is that it leave Phoneix in isolation. Components documented to require a particular lifestyle will only be functional (with confidence) within Fortress and Merlin
> That way Fortress and Merlin can both use @avalon-x (or @x-avalon) for > the lifestyle tag, and phoenix would just ignore it. If/when the point > in time comes that all containers are able to handle such components, > we could promote the tag to the @avalon namespace.
If we apply this approach from here on - a common Avalon container architecture is in effect impossible. That process involves active collaboration and compromise. For example, while the set of tags that Berin has proposed are workable relative to Merlin, they are not necessarily what I would choose in all cases - however, that's a small price to pay relative to the benefiot of moving forward.
> I see you & Berin's point Stephen, and I see Pete's. Both are valid.
If we were talking about this as "Phoenix must support these lifestyle semantics" - then Pete's aguments would have some validity. But we are not asking that. What we are asking is that a very small number of tags be addressed - each representing a semantic notion that exists in *all* containers. All this does is establish recognition that the semantic exists. Pete's argument is that the semantic does not exist at the level of a type. I think Pete's argument is wrong - and this can be easily shown in the Phoenix code (Phoenix applies the same semantics to all component types) and equivalent type level handling in both Fortress and Merlin.
The real issue here is what should happen when a container or tool encounters a type level criteria it cannot support.
Cheers, Steve.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
