You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2004/01/10 15:54:19 UTC
consensus-based development (was: Re: Avalon Meta != standard)
Stephen McConnell wrote:
> Leo Simons wrote:
>
>> given the decreased likelyhood of the Avalon-Meta package being in
>> broad use across different containers, I suggest we stop referring to
>> it as "standard", because its not.
>
> -1
you can't veto a suggestion dude! You also can't veto an assertion. I
think its a valid assertion, and an important one. You can try and argue
against all of that, and I probably won't feel like counter-arguing for
days, so if it comes to a vote you'll happily win. Shall I just keep my
mouth shut about everything then? Sure dude. You "win".
C'mon Steve, why do you think I say "suggest"? Because I'm friggin'
tired of having to argue about everything for days. And then hen having
to do it again every few months. Maybe you should try and listen rather
than make every communication into pro and con. Consensus-based
development imnsho does imply making an effort to avoid positions pro
and con.
> Without Avalon Meta your ability to establish portable components goes
> out the window.
Yeah. Let's rehash another old argument. Oh, no, wait, let's not.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: consensus-based development
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Stephen McConnell" <mc...@apache.org>
>
>>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.
>
>
> I dare to say : it will be easier :-) But I'm not sure it is the correct
> strategy.
>
> Hey, I don't know, I'm just some guy saying that we should start from the
> simplest thing and then - as necessity happens - going to complex
> environment. Your strategy is to keep Meta as it is and add migrations tools
> to others containers.
Correct.
> What about other containers store information in their
> specific way instead of Meta package pushing his own way/format? Thats my
> point. No migration tool would be need now.
That's also my point. If this scenario where endorsed - we would have
islands of components build for a particular container as opposed to
components that are build for Avalon compliance. That's a scenario that
am strongly opposed to.
> This conclusion came from the fact I already tried to adapt Fortress to Meta
> few months ago Well, didn't happen :-\
As far as I understand - the only issue that needs to be addressed is
the requirement that Fortress concerning a catalog of available
components. If a catalog is generated and supplied to Fortress (using a
Fortress specific build-time tool) then everything is available to
Fortress relative to the current Avalon Meta package. It can read in
the component type definitions, create and index of service providers,
index extension providers, and use these indexes when resolving
candidate components.
> There are few aspects that could drive our direction:
> * Existing containers
> * Existing application
> * New containers
>
> New containers could benefit from Meta package as it is. The problem exists
> in first two bullets. Answer my post pretending you're not Merlin developer,
> just someone with the big picture in hands and the background of the last
> week posts ;-)
Bottom line is this - if you are a component developer, it is desirable
to minimize the container specific overhead.
Take for example the overhead that Merlin places on a developer:
a) if they want to package profiles - they need to write
a Merlin specific xprofile descriptor
b) if the want to disable proxy handling - they need to
declare attributes in the meta-info descriptor that
is specific to the composition package
c) if they want to deploy a component they have to write
a block directive that is specific to the composition
package
d) if they want to change the personality of the container
they need to modify a merlin specific kernel description
Lets take these one by one.
For case (a) - the packing of deployment directives with a component
type .. well, Fortress uses a different meta-data model so Fortress
users would need to do something different (and they current do - its
called the roles file). At the end of the day would it not be better
that this sort of information was declared in a standard format?. But
to get to a standard meta-data model we need a standard meta-info model
(i.e. the expression of a requirement comes before the expression of a
solution).
Example (b) - the usage of container specific attributes - its an
example that demonstrates the weakness of the current model - in
particular, the current model does not expose the fact that an attribute
represents a runtime requirement. So ... something on the agenda for
implementation at the API and implementation level - standard attributes
that relate to runtime policies.
Example (c) - container specific meta-data ... have you every had to
deal with 160k Phoenix assembly file and wonder how your going to
migrate to another container? As we evolve our art - the question of
the component spec will fade in history because we will have resolved
each and every gray area. Instead - we will be focusing on the overhead
implied by container solutions. And here Avalon can set the container
meta-data reference.
Example (d) - this is what is going to send Phoenix to its grave, put an
end to Fortress, and give Merlin a such an identity crisis that for all
practical purposes - Merlin will exist only in our dreams.
Now ... to get back to your point "I'm not a Merlin developer and I'm
just someone impressed by last weeks traffic" ...
What I would do (as a container developer):
* write a tool the supports the translation of my user base to
the standard framework
* identify shortcomings with the implementation, investigate
discussions on how the implementation could evolve to better
meet additional/supplementary "semantic requirements",
contribute to the package development and evolution
* leverage the "standard" Avalon platform to the maximum
extent possible
What I would do (as a component developer):
* avoid anything that is container specific
* post comments to dev@avalon asking why anyone believes
that meta-info is not absolutely essential to the definition
of a binary-portable common component model
* ask the dev community why we haven't resolve a common
meta-data model
* ask the dev community what the road map is for the single
container architecture
- runtime component contract (done)
- meta-info (done)
- meta-data
- meta model API
- container SPI
But how do we get there? We get there by abstracting out a standard
framework.
* meta-info (component type requirements) - DONE!!!
* meta-data (assembly directives to a container) - COMING!!!
Avalon Meta only handles the meta-info side of the equation - i.e. the
simple stuff. But potential exists to migrate Merlin and Fortress
meta-data solutions to a standard model. Do that and your starting to
see a situation where Merlin and Fortress are simply implementations of
a Avalon component management architecture.
Wow - achieve this and nobody will care about which container - Merlin
will be dead, Fortress will be dead, we will just have the Avalon
platform, a reference implementation, and a bunch of pluggable facilities.
Cheers, Steve.
>
> regards,
> hammett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| 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
Re: consensus-based development
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> 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.
I dare to say : it will be easier :-) But I'm not sure it is the correct
strategy.
Hey, I don't know, I'm just some guy saying that we should start from the
simplest thing and then - as necessity happens - going to complex
environment. Your strategy is to keep Meta as it is and add migrations tools
to others containers. What about other containers store information in their
specific way instead of Meta package pushing his own way/format? Thats my
point. No migration tool would be need now.
This conclusion came from the fact I already tried to adapt Fortress to Meta
few months ago Well, didn't happen :-\
There are few aspects that could drive our direction:
* Existing containers
* Existing application
* New containers
New containers could benefit from Meta package as it is. The problem exists
in first two bullets. Answer my post pretending you're not Merlin developer,
just someone with the big picture in hands and the background of the last
week posts ;-)
regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: consensus-based development
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Leo Simons" <le...@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
Re: consensus-based development (was: Re: Avalon Meta != standard)
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Leo Simons" <le...@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.
- Fortress should implement its own Builder based on what is actualling
doing for service/components.
- Any other container should follow the same path.
The current Builder implementation is Merlin specific - and I agree should
not be considered an Avalon standard. 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)
Instead of pointing fingers to each other lets do what is necessary to do to
make things works as we expected - or at least think it is the desired
behavior. What about the XP practices in Avalon ? :-)
regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: consensus-based development
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Leo Simons wrote:
>>
>>> given the decreased likelyhood of the Avalon-Meta package being in
>>> broad use across different containers, I suggest we stop referring to
>>> it as "standard", because its not.
>>
>>
>> -1
>
>
> you can't veto a suggestion dude!
But I can type the characters "-1" in response to the suggestion and
though that indicate to you what my opinion is concerning the suggestion.
We have a framework specification that defines the computational
contract for components (the how), and complimenting this we have a the
meta-info specification (the what). Both go hand-in-hand in defining
what a component is and what it's expectations are.
It is the standard for defining *what* the component needs in a
container neutral way.
Cheers, Stephen.
--
|------------------------------------------------|
| 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