avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: consensus-based development
Date Sat, 10 Jan 2004 17:23:14 GMT
hammett wrote:

> ----- Original Message ----- 
> From: "Leo Simons" <leosimons@apache.org>
> 
> <...>
> 
> It may be not a standard yet, but lets be practical: how to make it
> standard?
> 
> My suggestion:
> - The current builder package (in impl) should move to Merlin.

The builder package contains the implementation of the readers of 
serialized and XML type and service descriptors.  It is used by the 
tools package and plugin package as part of the process of translating 
legacy content (such as Phoenix metainfo) to a standard form.

Rather than move the builder content (and by inference - tools and 
plugin) to Merlin, it would make more sense to add a migration tool to 
the Fortress package to ensure that meta-info is represented in a common 
way.

> - Fortress should implement its own Builder based on what is actualling
> doing for service/components.

A Fortress Migration tool could read in Fortress specific content and 
write this out to an Avalon Meta format.  The Fortress container could 
then either read this content in using the existing builder package, or 
write its own reader using the "standard" format for persistent meta-info.

> - Any other container should follow the same path.

The imperative aspect is the "standard" specification of a component 
descriptor and its packaging model such that any Avalon compliance 
component can be deployed within any container simply because we have a 
single "standard-binary-contract".

> The current Builder implementation is Merlin specific - and I agree should
> not be considered an Avalon standard. 

I agree that there are aspects concerning serialized forms that should 
not be considered as part of the Avalon standard persistent form (but 
the serialized forms can be used improve efficiency - for example, to 
cache Type descriptors).  However - I see nothing Merlin specific about 
this or any other characteristics of the builder implementation - but I 
also think its kind of a null-issue.  What exists provides a default 
implementation but that does not stop anyone from writing alternative 
implementations.

Even more important, I think that there are lots of things we can do to 
make the builder implementation more extensible - but I think that such 
development should be maintained within the meta package.

Cheers, Stephen.


> However the Meta package describes the
> flesh and bone of an Avalon component/services and related facilities. So
> its a good idea to use it an standard (I port it to .Net right this time and
> notice how its supress strategies I already made in my first container
> implementation)



-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

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


Mime
View raw message