You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/09 06:16:33 UTC
total domination - no prisoners
My thoughts for the day.
A quiet weekend brings me to the open subject of the resolution of a the
avalon component model and our support for the one true model.
According to Silvian Wallez, the one true model is a step too far in the
direction of too much magic. However - before we accept this as fact -
let's do a little analysis on where Silvian is coming from.
I'm confident that Silvian would appreciate the implicit magic in ECM,
for all intensive purposes it requires the obligatory usage of meta-info
in component implementations via the ROLE static member. Let's not stop
here - we also have the meta-data model implied (but not not specified)
under a the ECM roles configuration. Silvian is absolutely correct -
this is not magic. In effect it is an application specific deviation of
of the Avalon component model. Again - Silvian raises concerns relative
to Fortress - in particular the introduction of magic through the
automatic generation of unspecified meta. In this context I agree 100%
with Silvian.
Irrespective of my unbounded agreement with Silvian - I'm going to
disagree with Sylvian on a very basic principal. The Cocoon community
and for that matter all users of ECM and Fortress and are dealing with
meta information. The mysterious ROLE static value is nothing more that
the declaration by a component of the public service interface it
provides - and yet where is the avalon documentation for this? It does
not exist. Furthermore - the role file is pure loosely documented
meta-data, mapping "role" names to implementation solutions. Rather
than clearly and completely documenting these contracts (let alone
expressing these semantics in a formal API), the existence of ROLE has
been argued by a select few on the basis of "convenience" and even "the
intuitive approach". In effect the reality is that undocumented
semantics combined with a legacy implementation is the the only tangible
definition of LSD's "too much magic".
Back to Sylvian - and another point of agreement. Sylvian expressed his
personal support for the resolution within Avalon of a single community
backing a single solution. However - Sylvian expressed less that a 100%
conviction relative to this viewpoint. Why? I can't speak for Silvian
but I can speak for myself. We have a potential catch 22. There is
vocal minority that is expressing the opinion that we should not
consolidate our efforts on one platform without an equivalent
feature/benefit matrix so long as we have users of the another platform
- and in the same breath - why consolidate when we have a solution? The
real catch 22 here is that those who understand and appreciate the
ECM/Fortress model have not yet committed to the migration.
Over to Hammett - and the religious conviction theme. Hammett and I
actually agree on most things - but on this particular issue its black
and white:
Hammett's position:
* don't abandon Fortress before equivalent functionality is in
place - in the meantime "may the force be with you"
Steve's position
* forget about the "force" - its just a movie - focus on
reality and deliver the final solution as a collaborative
effort - reality is that the "force" is the community and
the community needs to consolidate and as long as we have a
division - the end-game remains elusive
So here is the dilemma. Follow the Hammett strategy and destroy the
dream. Follow the other strategy and take a risk. What to do?
How about the following:
* create the one solution community
* maintain a fullback strategy
* deliver more than we promise
In a somewhat related but independent thread Arron Far said (and I'm not
implying anything but a good text-stream from Aaron):
One container to rule them all
One container to find them
One Container to bring them all
And in the model bind them
And my answer was "yes" - meaning one model, total domination, no
prisoners. But how to achieve this? I think that irrespective of the
traffic - the consensus is reasonably close to closure. It's more about
"how" than "if". The how is about accommodating different priorities
with respect to a sustainable solution.
But maybe not. Chances are that I have this all wrong. Are there
additional points we should be taken into consideration before closing
this particular subject?
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
Re: total domination - no prisoners
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
>
> Irrespective of my unbounded agreement with Silvian - I'm going to
> disagree with Sylvian on a very basic principal. The Cocoon community
> and for that matter all users of ECM and Fortress and are dealing with
> meta information. The mysterious ROLE static value is nothing more that
> the declaration by a component of the public service interface it
> provides - and yet where is the avalon documentation for this? It does
> not exist. Furthermore - the role file is pure loosely documented
> meta-data, mapping "role" names to implementation solutions. Rather
> than clearly and completely documenting these contracts (let alone
> expressing these semantics in a formal API), the existence of ROLE has
> been argued by a select few on the basis of "convenience" and even "the
> intuitive approach". In effect the reality is that undocumented
> semantics combined with a legacy implementation is the the only tangible
> definition of LSD's "too much magic".
Just to address the ROLE static value issue, the MAJOR reason for that
value is to allow the compiler to catch spelling mistakes.
Granted, the ECM did follow some extra semantics which kind of forced Fortress
to follow suite to remain compatible in many respects.
There is nothing heinous or bad about allowing the compiler catch spelling
mistakes instead of discovering it at runtime.
As to documented semantics, they were documented on the website within the
DWA paper. When that was included in the paper, it was the basis of the
current mindset and set of best practices defined at that time. Extensive
discussion took place on this list all that time ago. You may go back in
the archives to look it up. However, to say it is undocumented is incorrect.
It is just not agreed to by "a select few" that happen to like to change
accepted patterns all the time.
This is just for clarification, so do with it what you will.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: total domination - no prisoners
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 09 March 2004 15:43, Stephen McConnell wrote:
> > Component Type Specification
> > Component Instance Identification Specification
>
> New territory for avalon but this is in the realm of managable stuff.
This is also already in place to some degree.
We have the issue regarding Merlin semantics of
"/somecontainer/somecomponent", but that refers to a "semi-instance", as it
depends on what LifeStyle that component is declared with.
There are heaps of other 'holes' here.
> > Component Dependency Specification
>
> Atructural is in place but I figure you thinking about the availability
> contract - no?
Partly. Currently there is no strict contract, just an implicit contract
defined in the container implementations. The beginning has started in form
of "@avalon.dependency" but I am sure, once one start digging into "optional"
and what should actually happen when dependencies can not be fulfilled, we
are in a whole new ballgame. Details are not relevant right now.
> > Component Packaging Specification
> Mre braincells need to die before this is closed.
Without it, it is no point dealing with the "Great Vision", and I will
continue the "Great Vision" elsewhere. But I do agree, there is room for
plenty of contention here.
> > Component Requirements Extension Specification
> Can you explain this one in more detail?
Well, it must be possible to create new contracts in the future, which are
either brand new, evolution of existing or replacements of existing
specifications. That means that the container that is created today need to
know how to behave when new contracts (which it doesn't understand) are going
to be treated, "fail" or "ignore" and how the components can signal this
contracts and behaviours.
So, this field is about "A specification on how to create new specifications."
But this is just the beginning of "missing pieces".
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: total domination - no prisoners
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 09 March 2004 18:39, Andreas Oberhack wrote:
> I feel our difference is just a matter of definition. What I mean is:
perhaps. :o)
> "one class with attached meta info == service".
> "A service, handling one or many other objects == component".
>
> What do you think?
This has been defined many times over in Avalon, and I think the current
definition is;
* Service; A contract of functionality, typically expressed as a java
interface.
* Component; One or many classes fulfilling one or many Service contracts.
My concern is that these definitions and all other contractual statements are
not rock-solid.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: total domination - no prisoners
Posted by Andreas Oberhack <de...@softwarefabrik.biz>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> > > 'class==component',
> > >
> > > > such granularity is too fine and is like Integrated Circuits
equals
> > > > transistor.
> >
> > I think, we will need both: components to "implement" a
functionality
> > and services, which "assemble" those components. Those service could
be
> > just a class - or a "component" in your terms.
>
> I strongly disagree.
> How do you identify a class, how do you version it, how do get its
> dependencies, how do you get the docs and javadocs, how do you put in
> I18N,
I feel our difference is just a matter of definition. What I mean is:
"one class with attached meta info == service".
"A service, handling one or many other objects == component".
What do you think?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: total domination - no prisoners
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 09 March 2004 16:42, Andreas Oberhack wrote:
> Hm - could we perhaps start with some definitions first? "component",
> "service", "plug-in", "extension", "facilities" etc. so that we know
> what to "tighten"? And by doing this it should be possible to define a
> high level architecture.
Well, yes, but that will be part of such an avenue...
> > 'class==component',
> >
> > > such granularity is too fine and is like Integrated Circuits equals
> > > transistor.
>
> I think, we will need both: components to "implement" a functionality
> and services, which "assemble" those components. Those service could be
> just a class - or a "component" in your terms.
I strongly disagree.
How do you identify a class, how do you version it, how do get its
dependencies, how do you get the docs and javadocs, how do you put in I18N,
how about other resources and so on and so on...
The strong packaging contract can always satisfy (if done correctly) the
'loose, laying around got in place 'somehow'' concept. But not the other way
around. And why do both?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: total domination - no prisoners
Posted by Andreas Oberhack <de...@softwarefabrik.biz>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Niclas Hedhman wrote:
> > On Tuesday 09 March 2004 13:16, Stephen McConnell wrote:
> >
>
> > One could ignore this for a moment, and accept that the containers
are
> here
> > now, and will not disappear in the near-future, and instead of
> concentrating
> > on a single container, we start to tighten up the "Component
Contracts"
> > instead.
Hm - could we perhaps start with some definitions first? "component",
"service", "plug-in", "extension", "facilities" etc. so that we know
what to "tighten"? And by doing this it should be possible to define a
high level architecture.
> 'class==component',
> > such granularity is too fine and is like Integrated Circuits equals
> > transistor.
>
I think, we will need both: components to "implement" a functionality
and services, which "assemble" those components. Those service could be
just a class - or a "component" in your terms.
All the best
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: total domination - no prisoners
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 09 March 2004 13:16, Stephen McConnell wrote:
>
>>My thoughts for the day.
>
>
> <snip content="interesting read" />
>
> But I would like to highlight that there is an alternate way to go about these
> concerns;
>
> The current approach is a lot about converging the existing container
> implementations and shoe-horn in the 'behaviour' of Fortress and ECM into
> Merlin.
Agree - but for social reasons - not technical.
> One could ignore this for a moment, and accept that the containers are here
> now, and will not disappear in the near-future, and instead of concentrating
> on a single container, we start to tighten up the "Component Contracts"
> instead.
Yes. I think its a viable strategy.
> We all know that there are endless holes in the contracts and semantics, which
> have led to the diverged containers.
>
> But I guess that the 'Flexibility Syndrome Camp' is quick to defend the loose
> contracts as a "feature". If so, I would like to buy these individuals a
> one-way ticket to Pico, since Avalon is not about (IMSO) 'class==component',
> such granularity is too fine and is like Integrated Circuits equals
> transistor.
I figure most of the tourist already have tickets.
We can move on with confidence.
> As we tighten the contracts, we have the choice to implement these in the
> existing containers, on the basis of OSS. Someone has the itch, they fix it,
> otherwise it remains unresolved.
OK .. classic approach.
> I also strongly recommend that the contract discussion is done without peeking
> into the container solutions that exists.
And on the other hand there is the value of validating contract
semantics against a reference implementation. I like that notion.
> I have a whole lot of issues at this end, I would like to "tighten", such as;
>
> Component Type Specification
OK.
> Component Instance Identification Specification
New territory for avalon but this is in the realm of managable stuff.
> Component Dependency Specification
Atructural is in place but I figure you thinking about the availability
contract - no?
> Component Packaging Specification
Mre braincells need to die before this is closed.
> Component Requirements Extension Specification
Can you explain this one in more detail?
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
Re: total domination - no prisoners
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 09 March 2004 13:16, Stephen McConnell wrote:
> My thoughts for the day.
<snip content="interesting read" />
But I would like to highlight that there is an alternate way to go about these
concerns;
The current approach is a lot about converging the existing container
implementations and shoe-horn in the 'behaviour' of Fortress and ECM into
Merlin.
One could ignore this for a moment, and accept that the containers are here
now, and will not disappear in the near-future, and instead of concentrating
on a single container, we start to tighten up the "Component Contracts"
instead.
We all know that there are endless holes in the contracts and semantics, which
have led to the diverged containers.
But I guess that the 'Flexibility Syndrome Camp' is quick to defend the loose
contracts as a "feature". If so, I would like to buy these individuals a
one-way ticket to Pico, since Avalon is not about (IMSO) 'class==component',
such granularity is too fine and is like Integrated Circuits equals
transistor.
As we tighten the contracts, we have the choice to implement these in the
existing containers, on the basis of OSS. Someone has the itch, they fix it,
otherwise it remains unresolved.
I also strongly recommend that the contract discussion is done without peeking
into the container solutions that exists.
I have a whole lot of issues at this end, I would like to "tighten", such as;
Component Type Specification
Component Instance Identification Specification
Component Dependency Specification
Component Packaging Specification
Component Requirements Extension Specification
I am sure this will grow ...
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: total domination - no prisoners
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
>
> Irrespective of my unbounded agreement with Silvian - I'm going to
> disagree with Sylvian on a very basic principal. The Cocoon community
> and for that matter all users of ECM and Fortress and are dealing with
> meta information. The mysterious ROLE static value is nothing more that
> the declaration by a component of the public service interface it
> provides - and yet where is the avalon documentation for this? It does
> not exist. Furthermore - the role file is pure loosely documented
> meta-data, mapping "role" names to implementation solutions. Rather
> than clearly and completely documenting these contracts (let alone
> expressing these semantics in a formal API), the existence of ROLE has
> been argued by a select few on the basis of "convenience" and even "the
> intuitive approach". In effect the reality is that undocumented
> semantics combined with a legacy implementation is the the only tangible
> definition of LSD's "too much magic".
Just to address the ROLE static value issue, the MAJOR reason for that
value is to allow the compiler to catch spelling mistakes.
Granted, the ECM did follow some extra semantics which kind of forced Fortress
to follow suite to remain compatible in many respects.
There is nothing heinous or bad about allowing the compiler catch spelling
mistakes instead of discovering it at runtime.
As to documented semantics, they were documented on the website within the
DWA paper. When that was included in the paper, it was the basis of the
current mindset and set of best practices defined at that time. Extensive
discussion took place on this list all that time ago. You may go back in
the archives to look it up. However, to say it is undocumented is incorrect.
It is just not agreed to by "a select few" that happen to like to change
accepted patterns all the time.
This is just for clarification, so do with it what you will.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: total domination - no prisoners
Posted by Andreas Oberhack <de...@softwarefabrik.biz>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> Simply put, there's no business case to be made for the migration
> effort.
good point!
>
> An aside: Part of the reason I'm into this aspect-container
> (whatever I'll end up calling it), is to provide this type
> of scalability. You should be able to build an Avalon app
> server, but also build something much smaller.
Again a very good point!
So my conclusion:
1. Let's define component contracts as "rock-solid" and stable as
possible, having a bunch of testcases to ensure every aspect of those
contracts. This is what our "customers" are requesting and what makes
Avalon attractive to them and us. As less as possible migration needs in
the long future!
2. Let's try to modularize the core as much as possible, so that it can
be configured to different needs. This will broaden the user basis for
Avalon and makes it "the container of choice"
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: total domination - no prisoners
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> I'm confident that Silvian would appreciate the implicit
> magic in ECM, for all intensive purposes it requires the
> obligatory usage of meta-info in component implementations
> via the ROLE static member.
No.
ROLE isn't obligatory. ECM doesn't know/care that it is there.
> The mysterious ROLE static value is nothing more that
> the declaration by a component of the public service interface it
> provides
No. It is a convenience value that clients can (but not must) use
in the lookup() call.
> We have a potential catch 22. There is vocal minority that is
> expressing the opinion that we should not consolidate our efforts
> on one platform without an equivalent feature/benefit matrix so
> long as we have users of the another platform - and in the same
> breath - why consolidate when we have a solution? The real catch
> 22 here is that those who understand and appreciate the ECM/Fortress
> model have not yet committed to the migration.
You can only understand that against the background that *the container
doesn't matter*. No, really, it doesn't. When Carsten says that
"we use ECM, and that works fine", it isn't a reflexive "I can't be
bothered to look at your magnificent container" but a reasonable
position to take given business requirements.
It is as if someone jumped up and said that we should dump Java
and code in LISP/C#/Ruby instead, because it is just sooo much better -
just look at all these features! Who would care if there was a
migration strategy? Java works.
Simply put, there's no business case to be made for the migration
effort. Like you, I can only speak for myself - migrating to Merlin
would not translate into a single $ for me. It would not translate
into faster application development, not into easier deployment, not
into anyhing except another dependency (that drags 30+ dependencies
with it) and *a lot of effort* in migrating. It would translate into
having a complete component model, but what do I *gain* from that?
> Over to Hammett - and the religious conviction theme. Hammett and I
> actually agree on most things - but on this particular issue
> its black and white:
>
> Hammett's position:
>
> * don't abandon Fortress before equivalent functionality is in
> place - in the meantime "may the force be with you"
>
> Steve's position
>
> * forget about the "force" - its just a movie - focus on
> reality and deliver the final solution as a collaborative
> effort - reality is that the "force" is the community and
> the community needs to consolidate and as long as we have a
> division - the end-game remains elusive
>
> So here is the dilemma. Follow the Hammett strategy and destroy the
> dream. Follow the other strategy and take a risk. What to do?
Follow Hammett's strategy and have working applications, follow the
other strategy and risk a lot for nothing. I'm not quite sure what
reality you want me to focus on.
> How about the following:
>
> * create the one solution community
> * maintain a fullback strategy
> * deliver more than we promise
>
> In a somewhat related but independent thread Arron Far said
> (and I'm not
> implying anything but a good text-stream from Aaron):
>
> One container to rule them all
> One container to find them
> One Container to bring them all
> And in the model bind them
There is a gain in plugging holes in the Framework contracts -
that much of the model I support. That should be enough to give
us portable components. But I think that the "model" you
talk about is the Merlin model - the parts of merlin that isn't
Framework - and I really do have a problem with that part, because
it is heavyweight and not that flexible. It's as big as J2EE,
but without the industry support.
> But maybe not. Chances are that I have this all wrong. Are there
> additional points we should be taken into consideration
> before closing this particular subject?
Yes, what model?
Niclas lists:
+ Component Type Specification
+ Component Instance Identification Specification
+ Component Dependency Specification
+ Component Packaging Specification
+ Component Requirements Extension Specification
Now that's a *lot* of stuff.
Take Component Packaging for example. Does this mean packaging
as in ear/war/ejb-jar files? If so, can you guarantee that this
will in fact work in many environments where Avalon is used?
If not, does it make sense to exclude those and their
developers?
Avalon isn't an App Server. We have J2EE for that. Avalon is
an IoC framework that currently excels at being used inside
J2EE - inside servlets, inside MBeans, inside bizarre
classloader hierarchies... you name it. And all this because
of flexibility and a short and simple specification that
only concerns itself with the very basics.
I don't want to throw that part of Avalon away.
As Niclas said, maybe I should take that ticket to Pico.
An aside: Part of the reason I'm into this aspect-container
(whatever I'll end up calling it), is to provide this type
of scalability. You should be able to build an Avalon app
server, but also build something much smaller.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org