You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/06/14 16:34:28 UTC
The need for 'hints'
Peter Donald wrote:
>
> Berin wrote:
>
> >ConnectionManager ssl = (ConnectionManager)
> > m_manager.lookup(ConnectionManager.ROLE + "/SSL");
> >
> >and this:
> >
> >ConnectionManager ssl = (ConnectionManager)
> > m_manager.lookup(ConnectionManager.ROLE, "SSL");
>
> Loss of clarity and added complexity.
>
> 2 extra methods that are uneeded except by Cocoon.
I'll try to keep this abstract and I remove my cocoon hat.
First,
ConnectionManager ssl = (ConnectionManager)
m_manager.lookup(ConnectionManager.ROLE + "/SSL");
is a hack.
I'm pretty sure that this is obvious to everyone.
Now Peter asks: do we really need hints?
Let me try to ask this
- o -
Play example
------------
An actor asks the director who is the actor who plays a particular role
*AND* will act as a replacer if the actor appointed for that role is
sick the night the play gets on stage.
If you don't have hints, it is up to the director to know that in that
particular lookup, the actor wanted to do a particular 'flavor' of that
lookup.
Is the behavior ignorable? yes, totally. A director might not take into
consideration the lookup flavor and simply perform a lookup.
What, How and Who
-----------------
A two-dimensional lookup is required when the knowledge of the lookup is
obtained by aggregating information from two separate concerns. The
first dimension is the role (what), the second dimension is the hint
(how).
The lookup mechanism hides the "who", which is given by the director
inverting the control and allowing transparent polymorphism.
But I do not understand what is wrong in allowing a component to ask for
"what" and suggest "how", since it is its own concern to use that
component so it must have the control to specify both 'what' and 'how'.
I think this concept is elegant and general enough to deserve to remain
in the next version of Avalon.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
> If personal attacks are the order of the day the, here is my attack then.
> <JaneYouIgnorantSlut>
> Sure seems like a high signal to noise ratio. Kind of hard to ferret
> out the message sometimes.
> </JaneYouIgnorantSlut>
>
> There, I feel better now. Except for the JaneYouIgnorantSlut thing. Need
> to find a less obvious tag.
>
how about
<<the following section has been edited for content>>
;)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
>
>
>>>I can't figure out if you guys are all just young where it doesn't hurt
>>>yet, or I have just become too tender,
>>>
>>>
>In dinosaurs, thick skin comes with age...anyways....
>
>
Got me pegged on the dinosoar part. Creak plod creak plod creak. Must
have a bad skin gene though, because mine just keeps getting more tender.
>>Anyways most of us have been around long enough to know that no offense is
>>intended - however it is probably not so obvious to newer people ;)
>>
If personal attacks are the order of the day the, here is my attack then.
<JaneYouIgnorantSlut>
Sure seems like a high signal to noise ratio. Kind of hard to ferret
out the message sometimes.
</JaneYouIgnorantSlut>
There, I feel better now. Except for the JaneYouIgnorantSlut thing. Need
to find a less obvious tag.
>>
>>
Re: The need for 'hints'
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>
> FA, one of our more recent joinees, Nicola Ken (sorry to make an example
> of ya ;
I'm honoured! :-)
> ), who has also dared to participate in this, heated, thread, has
> not had to deal with 'personal attacks' of any kind.
I know I'm an asshole, no need to hear it from you ;-D
> Even recognizing all this, I also find it very annoying that discussion
> indeed sometimes becomes more than argumentative. But when you've got
> Ozzies, French, and worse (:-P), well, that's the way it has to be, I
> guess.
Yeah ;-)
I came in quite strong because I'm als ao committer in Cocoon, POI,
Forrest, Krysalis stuff.
Thank you for being kind.
Now that I'm accustomed and have my asbestos suit on, I'm ready for
personal attacks too ;-P
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-06-19 at 04:34, Peter Donald wrote:
> On Wed, 19 Jun 2002 11:45, Pete Carapetyan wrote:
> > Peter Royal wrote:
> > >Having worked with Phoenix (*and* Cocoon/ECM) I came to the understanding
> > >that you and Stephen are promoting the correct solution. And the common
> > >metainfo discussions are the path that we should be persuing with vigor at
> > >the moment.
> > >
> > >I'm just not as good as you at the clever and sarcastic explanations
> >
> > I can't figure out if you guys are all just young where it doesn't hurt
> > yet, or I have just become too tender,
In dinosaurs, thick skin comes with age...anyways....
> > The phrase someone laid on me, I think, is *ad hominum* which describes
> > the making of a personal attack as a part of the discussion.
yup, sounds like OSS development alright. The good part is that the
attack is at least in the open (in Real Life(tm), it often is not) for
everyone to judge. (go ahead, be judge, shout back: THAT IS NOT A FAIR
COMMENT. They'll probably admit it.)
> Anyways most of us have been around long enough to know that no offense is
> intended - however it is probably not so obvious to newer people ;)
exactly. Can remember first discussion Pete and Berin got into about all
this when I was new here - pretty scary, that was.
I think you will also notice that the mudslinging, when it happens, is
between the developers that have been around a bit longer, and know each
other. Most OSS projects try and be very careful of their "newbies", as
doing so is vital to the project.
FA, one of our more recent joinees, Nicola Ken (sorry to make an example
of ya ;), who has also dared to participate in this, heated, thread, has
not had to deal with 'personal attacks' of any kind.
Even recognizing all this, I also find it very annoying that discussion
indeed sometimes becomes more than argumentative. But when you've got
Ozzies, French, and worse (:-P), well, that's the way it has to be, I
guess.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
On Wed, 19 Jun 2002 11:45, Pete Carapetyan wrote:
> Peter Royal wrote:
> >Having worked with Phoenix (*and* Cocoon/ECM) I came to the understanding
> >that you and Stephen are promoting the correct solution. And the common
> >metainfo discussions are the path that we should be persuing with vigor at
> >the moment.
> >
> >I'm just not as good as you at the clever and sarcastic explanations
>
> I can't figure out if you guys are all just young where it doesn't hurt
> yet, or I have just become too tender,
In most cases you have to be fairly thick skinned and egotistical to survive
most opensource projects ;) Especially ones like Avalon/Framework which is
lite on code and heavy on conceptual ideas.
> The phrase someone laid on me, I think, is *ad hominum* which describes
> the making of a personal attack as a part of the discussion.
I think you will find that the "personal attacks" are less part of argument
and more decoration on argument aimed at producing a response. People tend to
defend their ideas more strongly when their names are attached to message.
For example, recently the discussion on whether Stephens use of short role
names (like "ssl-socket-manager") vs the rest of us that use interface name.
I initially thought he was on some religious tangent. Only by keep
"attacking" him where we able to discover that the reason he was using them
was quite sensible (namely as he exposes the names to assemblers/admins).
Other containers (like Cocoons or Myrmidons) actually map the classnames to
"shortnames" and thus never expose admins/assemblers to the long names. If we
hadn't had badgered Stephen we wouldn't know this and thus we couldn't try to
fix it in the future. Now that we know that this practice has arisen from
weaknesses in Phoenix/Merlin we can now attempt to fix the weaknesses in the
future.
Anyways most of us have been around long enough to know that no offense is
intended - however it is probably not so obvious to newer people ;)
BTW this is very very very very very mild to some of the discussions in
history ;)
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
> > I can't figure out if you guys are all just young where it doesn't hurt
> > yet, or I have just become too tender, but all these terrific
> > discussions punctuated with quite personal attacks are a bit of an *ouch*.
>
>
> One thing for all: have you ever seen a women subscribed to this list?
>
> In Cocoon, I had a very hard time making people to understand that
> ego-based battles scare women away, no matter how
> smart/brilliant/capable/useful/nice/strong-egoed they are. It's their
> nature... like ego-fighting is ours. Nicola knows what I'm talking about
> since he almost managed to piss each one of them off simply by stating
> something in the wrong way.
*please* don't generalize...you make it sound like you can piss all
women off by stating something in the wrong way.
One of the reasons there aren't much women involved in open source
software development is that there aren't much women involved in
software development. Those that are often know how to deal with the
social disasters many programmers are.
phrase the question like: of the female geeks you know, how many are
subscribed to this list?
> Some people on this list follow Jon Stevens's patterns: fight 'till the
> opponent surrenders (or leaves).
>
> Let me tell you: Avalon is doomed if this attitude is kept.
would be nice if that were true. Emacs is in widespread use, innit, as
is GNU/linux...
> Sure, we are
> debating as some philosophical issues here and it's hard to remain
> perfectly neutral and dissipate the negative energy that develops, but
> at least, one should *be aware* that such negative energy (sarcasm,
> personal attacks and so on) DO NOT make a community stronger, nor
> development better.
+5000
> Some believe that this razor sharp attitude makes the community sharper
> on technical details... My experience tells me the exact opposite: it
> scares possible new contributors away.
+10000
> Over the years, I came up with a design pattern for this: 'when you feel
> personally attacked, write a nasty mail back and then delete it without
> sending it, then start over again, you'll see all the negative energy
> dissipated and you see what the other says'.
I do the same thing, though I usually mention when I do (one thing that
ends an ego battle is to admit that you found your ego badly hurt and
that you would like the battle to end because it is not worth it).
> I must admit I use this pattern everytime Peter writes something to me
> and this is *very* annoying. He would be *much* more helpful if he
> stopped this (admittedly defensive) attacking attitude.
Have you mentioned this to him before? Presenting this information now,
in this thread, is hardly helpful; you add a personal dimension to what
started mostly as an abstract discussion.
> Sure, we are all sellfish and egocentric, that's our big human problem,
> but it's not an excuse not to try to improve ourselves before trying to
> improve the software we write.
yup.
Another thing I have noticed: the fact that e-mail is often very much an
unpersonal way of communication, where code is not, means that there is
added difficulty in building and maintaining a community.
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 10:35 AM 6/19/2002 +0200, Stefano wrote:
>Let me tell you: Avalon is doomed if this attitude is kept.
Is this the "sky is going to fall unless you listen to me" speech ... again?
Nice attack though.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
>
>
>Let me tell you: Avalon is doomed if this attitude is kept. Sure, we are
>debating as some philosophical issues here and it's hard to remain
>perfectly neutral and dissipate the negative energy that develops, but
>at least, one should *be aware* that such negative energy (sarcasm,
>personal attacks and so on) DO NOT make a community stronger, nor
>development better.
>
>
>
It is the signal to noise ratio that is more bothersome to me. SoC,
basically. It takes friggin 8 nasty back and forth emails that I gotta
trudge through before I figure out that Jimmy or Johny's concern is
keeping the meta-info in one place. A lot of work to filter. But
meanwhile, because the meta-info in one place issue is buried in those 8
emails, by the time it gets summarized another 20 attacks and threads
have spawned, so it never gets pegged as a key value. Round and Round
and Round. You would never code that way, new threads spawning all over
the place for god knows what reason. You would keep the footprint low,
IoC it, and take care of business. Why not the same rules in discussion?
But only for practicality sake, not for moral reasons.
>Sure, we are all sellfish and egocentric, that's our big human problem,
>but it's not an excuse not to try to improve ourselves before trying to
>improve the software we write.
>
Personal stuff is SoC - not an issue, only my behaviour as it affects
the flow matters. The practical issue is that I got limited time and
absorbtion capacity. Oh wait, that is a personal problem too. Oh well.
My sense of the situation is that the only reason we have the attack
style of discussion is that it is a lot of fun. If it wasn't fun, we
wouldn't be here. Or is that true? Can't say.
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Pete Carapetyan wrote:
>
> Peter Royal wrote:
>
> >Having worked with Phoenix (*and* Cocoon/ECM) I came to the understanding
> >that you and Stephen are promoting the correct solution. And the common
> >metainfo discussions are the path that we should be persuing with vigor at
> >the moment.
> >
> >I'm just not as good as you at the clever and sarcastic explanations
> >
> I can't figure out if you guys are all just young where it doesn't hurt
> yet, or I have just become too tender, but all these terrific
> discussions punctuated with quite personal attacks are a bit of an *ouch*.
>
> The phrase someone laid on me, I think, is *ad hominum* which describes
> the making of a personal attack as a part of the discussion. Appears to
> violate some SoC pattern of communication.
>
> Speaking only for myself of course, I have been amazed at the quality of
> intelligence among participants, and have not seen one person yet who
> seems worthy of such a personal attack. Very sharp fellows, one and all.
>
> Nice place to learn about how to understand Avalon better though! Just
> hard to filter through all the <JaneYouIgnorantSlut/> stuff. At least I
> finally am beginning to get a handle on which containers are blessed,
> and which not, and how to use certain methods. This is good, thanks.
Let me tell you something: I'm not scared by personal attacks... in
fact, I developped my thick skin in OSS and I helped me a lot in real
life as well... but I'll tell you guys something that you might not
experienced before: razor-sharp ego battles like avalon's (or those who
happen over at members@apache.org or a fight with rms@gnu.org, which are
orders of magnitude sharper believe me! I usuallly got beat up quite bad
in those locations) keep a community still.
One thing for all: have you ever seen a women subscribed to this list?
In Cocoon, I had a very hard time making people to understand that
ego-based battles scare women away, no matter how
smart/brilliant/capable/useful/nice/strong-egoed they are. It's their
nature... like ego-fighting is ours. Nicola knows what I'm talking about
since he almost managed to piss each one of them off simply by stating
something in the wrong way.
Some people on this list follow Jon Stevens's patterns: fight 'till the
opponent surrenders (or leaves).
Let me tell you: Avalon is doomed if this attitude is kept. Sure, we are
debating as some philosophical issues here and it's hard to remain
perfectly neutral and dissipate the negative energy that develops, but
at least, one should *be aware* that such negative energy (sarcasm,
personal attacks and so on) DO NOT make a community stronger, nor
development better.
Some believe that this razor sharp attitude makes the community sharper
on technical details... My experience tells me the exact opposite: it
scares possible new contributors away.
Over the years, I came up with a design pattern for this: 'when you feel
personally attacked, write a nasty mail back and then delete it without
sending it, then start over again, you'll see all the negative energy
dissipated and you see what the other says'.
I must admit I use this pattern everytime Peter writes something to me
and this is *very* annoying. He would be *much* more helpful if he
stopped this (admittedly defensive) attacking attitude.
Sure, we are all sellfish and egocentric, that's our big human problem,
but it's not an excuse not to try to improve ourselves before trying to
improve the software we write.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Peter Royal wrote:
>Having worked with Phoenix (*and* Cocoon/ECM) I came to the understanding
>that you and Stephen are promoting the correct solution. And the common
>metainfo discussions are the path that we should be persuing with vigor at
>the moment.
>
>I'm just not as good as you at the clever and sarcastic explanations
>
I can't figure out if you guys are all just young where it doesn't hurt
yet, or I have just become too tender, but all these terrific
discussions punctuated with quite personal attacks are a bit of an *ouch*.
The phrase someone laid on me, I think, is *ad hominum* which describes
the making of a personal attack as a part of the discussion. Appears to
violate some SoC pattern of communication.
Speaking only for myself of course, I have been amazed at the quality of
intelligence among participants, and have not seen one person yet who
seems worthy of such a personal attack. Very sharp fellows, one and all.
Nice place to learn about how to understand Avalon better though! Just
hard to filter through all the <JaneYouIgnorantSlut/> stuff. At least I
finally am beginning to get a handle on which containers are blessed,
and which not, and how to use certain methods. This is good, thanks.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Royal <pr...@apache.org>.
On Monday 17 June 2002 08:47 pm, Peter Donald wrote:
> Does that make it any clearer?
> The key points are;
>
> * separating the lookup key for dependency from set of constraints
> associated with dependency
> * simplifying interface from user perspective and making it harder to abuse
> the
> * separating out separate stages/views (ie assembler vs develoepr view).
> * easing product evolution
I read your posts, and agree with you 100%.
Having worked with Phoenix (*and* Cocoon/ECM) I came to the understanding
that you and Stephen are promoting the correct solution. And the common
metainfo discussions are the path that we should be persuing with vigor at
the moment.
I'm just not as good as you at the clever and sarcastic explanations (plus
i'm *really* busy in real life at the moment :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
On Wed, 19 Jun 2002 02:58, Stefano Mazzocchi wrote:
> > Perhaps it is better to describe it in terms of a hypothetical container
> > that could be created once I finish the new metainfo stuff. Consider a
> > component X. Associated with that component is some metainfo and assuming
> > it is a similar format to Phoenixs Blockinfo assume it has a section such
> > as
> >
> > <component>
> > ...
> > <dependencies>
> > <dependency>
> > <role>my-transformer</role>
> > <service classname="org.apache.cocoon.api.Transformer"/>
> > <attribute name="type" value="xslt"/>
> > </dependency>
> > </dependencies>
> > ...
> > </component>
> >
> > This saids that X has a dependency on a component that implements
> > interface org.apache.cocoon.api.Transformer, is of type "xslt" and is
> > accessed from ComponentManager using the key "my-transformer". Note I
> > have intentionally left "type=xslt" undefined as it is a container
> > specific concept. (Alternatively you may do something like
> > "handles-dtd=..." or whatever).
> >
> > <service/> + <attribute/>s == constraints on dependency
> > <role/> == key used to lookup component
> >
> > So all the container needs to do is lookup a component with the key
> > "my-transformer" and the correct component is returned.
>
> Cocoon needs a 2-d lookup space, this is not going to change in the
> future. The above doesn't give it to me unless I namespace the key:
The above gives you N dimensional lookup space. Think about it.
<service/> is one dimension. The 0-N attributes included with dependency add
0-N dimensions to dependency. The above declares 2 - exactly what cocoon
needs.
> > * Merlin will auotmatically assemble the application. ie For each
> > dependency it will look for potential providers among other components.
> > If there is only one potential provider it will use that. If there is
> > more than one potential provider then it will select one based on some
> > heuristic (it uses a "policy" (aka "hint") attribute).
>
> Ok, great. So, what's wrong with
>
> lookup(role, policy)
Well if you like scattering metainfo in both code and descriptors, mixing
concerns between developers and assemblers, complicating the life of
component writers, and making it a bitch to do evolution then nothing is
wrong with it - it is great.
> Moreover, you are explicitly stating that other containers (Merlin) need
> that, so what's the damn problem with a 2-d lookup mechanism?
re-read above.1-d, 2-d, 57-d - it does not matter.
The dependency has a single name and that name refers to the set of
dimensions. If containers want to support extra dimensions then they can with
zero hassles.
Want to create dimension/constraint so that you only suck down a component
capable of handling DTD X then you can, want to add another dimension
indicating you will only accept component that is ThreadSafe then you can.
The number of dimenions is limited only by the container writers imagination.
> Yes, I like what I see conceptually, but I don't see, from what I
> understood, why you feel that a 2-d lookup space (role,policy) is bad.
It puts metainfo inside code which is BAD BAD BAD ;) And will always come back
to bite you if the system needs to be maintained.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 19 June 2002 09:59 am, Stefano Mazzocchi wrote:
> I'm still worried about the fact that it will be harder to push in the
> direction of A5 if less functionality is provided to Cocoon than A4
> (which works well for us today) and more stuff will have to be rewritten
> by ourselves directly.
>
> I do see the need for it, since it's true: Cocoon uses Avalon to manage
> the lookup of both *real* Avalon components (those that should be
> portable) and for cocoon components (that should *not* be portable
> because it wouldn't make any sense to try to do so)
>From what I've seen, I don't think *too* much rewriting will be neccessary.
At most, some bits will be moved back from excalibur to cocoon. (For
instance, the usage of a ComponentSelector can come back to cocoon as an
AbstractPipelineComponentManager).
I'm seeing more refactoring not rewriteing.
> I think the catch-22 issue comes from the fact that Cocoon used Avalon
> too much, even where it didn't make sense. You guys now want to refactor
> it and clean its mistakes and I agree that Cocoon should not force bad
> design decisions because of past abuse.
whoho!
> I call for a restate of the Avalon's project charter!
Where is the current charter? I didn't see it immediately on the website.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 12:04 PM 6/23/2002 +0200, you wrote:
> > > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > >
> > > > Leo (A Cocoon developer) saids a killer feature would be to change
> > > > cocoon to not be directly referentiable.
> > >
> > > Stefano (another Cocoon developer) asks how this is possible
> > > if the direct referencing of components is hardcoded into the
> > > sitemap semantics.
> >
> >Leo (the Cocoon "developer" first mentioned, although strictly speaking
> >he's not a committer to Cocoon and has contributes very few patches)
> >wonders what "directly referentiable" means.
>
> Essentially whether you use a local namespace per component or access a
> global namespace from every component. If you use local namespaces for
> components they indirectly refer to components in global namespace.
Example:
<sitemap>
<components>
<generators>
<generator name="blah" src="com.mystuff.MyGenerator"/>
</generators>
...
</components>
<pipelines>
<pipeline>
<match pattern="**">
<generate type="blah" src="{1}.xml"/>
...
</match>
</pipeline
</pipelines>
</sitemap>
the sitemap semantics perform a direct lookup of the component
implementing the "Generator" interface, using the 'generate/@type'
attribute to match the 'generators/@name' attribute.
This is the assembly information we have and can be included in the same
sitemap or in the parent sitemaps.
Using the ComponentManager that Berin proposed for A5, the above is easy
to implement using.
Generator generator = (Generator) lookup(Generator.ROLE,"blah");
which appears (to us) much more elegant than
Generator generator = (Generator) lookup(Generator.ROLE+"/blah");
You could say that we could use:
Generator generator = (Generator) lookup("blah");
but in that case, you'd have to implement proper namespacing, such as
Generator generator = (Generator) lookup("generator:blah");
to avoid conflicts with other components called 'blah', or, following
ICANN patterns, get back to
Generator generator = (Generator) lookup(Generator.ROLE+":blah");
Generator generator = (Generator) lookup(Generator.ROLE+"/blah");
Generator generator = (Generator) lookup(Generator.ROLE+"[blah]");
or other ways to encode the 2d-mapping into a 1d component query string.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 12:04 PM 6/23/2002 +0200, you wrote:
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > > Leo (A Cocoon developer) saids a killer feature would be to change
> > > cocoon to not be directly referentiable.
> >
> > Stefano (another Cocoon developer) asks how this is possible
> > if the direct referencing of components is hardcoded into the
> > sitemap semantics.
>
>Leo (the Cocoon "developer" first mentioned, although strictly speaking
>he's not a committer to Cocoon and has contributes very few patches)
>wonders what "directly referentiable" means.
Essentially whether you use a local namespace per component or access a
global namespace from every component. If you use local namespaces for
components they indirectly refer to components in global namespace.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Stefano Mazzocchi wrote:
>composer: I need a component that implements 'screwdriver' and I'll use
>it on screws of 3 mm of diameter.
> componentManager: here it is
>
>It has been suggested that the working context is just another
>information you pass in the role, so, in our examples, we would have an
>inflation of roles for each screwdriver and each possible screw size or
>size ranges.
>
>Please, tell me, am I the only one who doesn't get a good feeling out of
>this?
>
<outOfMyLeague>
From a distance looks as if you are trying to accomplish inheritance
through metadata. If that is the case, wouldn't it be much more
straightforward to provide for component inheritance. Like, give me a
No2FlatHeadScrewdriver? Which also, by the way is a Screwdriver. Surely
I am missing something.
I personally don't see how a COP would ever work without some level of
component inheritance anyway, and it would seem more straightforward
than through hints.
<outOfMyLeague/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> No, it is clear now and it was clear before, just that I do not perceive
>
> lookup(role,hint);
>
> and
>
> lookup(role+"/"+hint);
>
> to be architectrually equivalent since they represent two different
> cognitive ways to access to components
Correct.
> and we loose completely the
> ability to match a role to a java interface.
Which is exactly what the proposers of this say: a role is not an
interface, it's just a "tag".
> While using java interfaces for metadata is a limited approach, at least
> it allowed stronger typing. The same can be said for 'role = interface'.
The fact is that the lookup they proposed is not based on roles.
The roles and other metadata are bound by the container, not requested
by the lookup...
> Anyway, since it seems like I'm the only one having such vision, I'll
> shut up and let you guys do your job.
You're not the only one, I still think that it's more natural to ask for
a component using
lookup(role, metadata)
In fact, since I must do a cast, it's reasonable to thik that role is an
interface:
(Role) myobj = (Role)lookup(role, metadata)
Of course, metadata can be more than a string, the fact is that I have
role=what and metadata=how.
The only way in which Java enforces "whats" is by interfaces.
This said, I would like to see answers to all the points I've written
here, so that I can understand better why it's a bad idea.
Maybe I should not call it lookup(), maybe I'm doing the wrong thing...
-oOo-
Anyway, let me try to see alternatives.
Now, lookup(role, metadata) can be intuitive, but how is it used?
Well, role is fixed, while metadata could be fixed or not.
If metadata is fixed, ok, I'm just doing a fixed lookup and I could as
well use a single String to do the lookup...
But I loose the evidence that I'm requesting a component with the strong
contract of an interface.
As for dynamic lookups, I will have a fixed role but varying metadata...
But how do I do the right lookup?
I need to
1. know beforehand all possible components
2. or take a look at the descriptor
But
1. lookup is useless to me if I need to do all the work
2. I'm breaking encapsulation
Static example using a String as metadata.
------------------------------------------
String RoleString=Role.class.toString();
Role myobj1 = (Role) lookup(RoleString, "one");
Role myobj2 = (Role) lookup(RoleString, "two");
Static example using a fixed lookup
------------------------------------
Role myobj1 = (Role) lookup("tag1");
Role myobj2 = (Role) lookup("tag2");
Dynamic example using a String as metadata.
------------------------------------------
String RoleString=Role.class.toString();
ArrayList Metas = userrequests.getMetas();
RoleArrayList MyObjs = new ArrayList;
for(int i=0; i<Metas.size(); i++)
{
RoleArrayList.addObj((Role) lookup(RoleString, Metas.get(i));
}
Static example using a fixed lookup
------------------------------------------
?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> >
> > Playing the stubborn role at least brought some unification
> > back, which is a good thing, no matter how much my ego is
> > satisfied with the resoluzion :)
> >
> > No, it is clear now and it was clear before, just that I do
> > not perceive
> >
> > lookup(role,hint);
> >
> > and
> >
> > lookup(role+"/"+hint);
> >
> > to be architectrually equivalent since they represent two
> > different cognitive ways to access to components and we loose
> > completely the ability to match a role to a java interface.
>
> Stefano. There are several component architectures in existence.
> Each one of them has the concept of lookup, container, component,
> and client. This is true of CORBA, COM, EJB, Servlet, Avalon,
> etc. The one thing that is different about Avalon from all the
> other component architectures is the lookup.
>
> The other component architectures *bind* components or component
> stubs to a namespace. That namespace can be hierarchical (i.e.
> use directories), or flat. EJBs and Servlets use JNDI. CORBA
> uses the COS Naming Service. COM uses another mechanism (I am
> not as familiar with that).
>
> Everywhere we need to use constraints (i.e. hints), it is usually
> done from a container/component. The hybrid container/component
> acts as both a container and a component. Take advantage of this
> fact, and access the components you need directly.
>
> > While using java interfaces for metadata is a limited
> > approach, at least it allowed stronger typing. The same can
> > be said for 'role = interface'.
>
> However, it causes problems with inheritance. Consider if you
> will something that until I brought it to the Cocooners attention
> was rather common. An abstract base class for component
> implementations implements the ThreadSafe interface. A concrete
> implementation that extends the abstract class implements the
> Poolable interface. So which is it? Because of this fiasco,
> we were forced to put in some checks that would throw an exception
> if there were multiple LifeStyle interfaces implemented for a
> component.
Great point, I missed it before.
> We were also forced to adopt the practice of not declaring lifestyle
> until the component was concretely implemented. The inheritance
> of lifestyle seemed like a good approach at first, but it caused
> more problems than it solved.
>
> Not to mention it is difficult to authoritatively say how the
> component would be treated in the container.
>
> That is why Fortress, Merlin, Phoenix, et. al. declare the lifestyle
> and other meta information in the component descriptor. The
> developer can say with confidence which creational policy (lifestyle)
> was used for their component. There was less ambiguity and less
> chance for inheritance causing problems.
Ok, I'm sold.
> Furthermore, with the role = interface issue in over half of the
> cases it is sufficient. However, the container has no way of
> knowing what the component needs in terms of external components.
> By using meta data, we can implement a more *secure* system by
> only allowing a component to see the external components it
> needs or is registered for. As it is now, a component can freely
> try interface names to attempt to control or cause internal DoS
> attacks because role=interface and there is no scoping of what
> the component can see.
>
> We can develop a far more secure system that is more architecturally
> unfriendly to deviant components that might be loaded in at runtime
> because role != interface, and the component can only see what it
> is allowed to see.
>
> The container can have the needed control to provide a secure
> environment.
>
> >
> > Anyway, since it seems like I'm the only one having such
> > vision, I'll shut up and let you guys do your job.
>
> Don't sound so defeated.
Ok, got your points: I'll follow you guys.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
>
> Playing the stubborn role at least brought some unification
> back, which is a good thing, no matter how much my ego is
> satisfied with the resoluzion :)
>
> No, it is clear now and it was clear before, just that I do
> not perceive
>
> lookup(role,hint);
>
> and
>
> lookup(role+"/"+hint);
>
> to be architectrually equivalent since they represent two
> different cognitive ways to access to components and we loose
> completely the ability to match a role to a java interface.
Stefano. There are several component architectures in existence.
Each one of them has the concept of lookup, container, component,
and client. This is true of CORBA, COM, EJB, Servlet, Avalon,
etc. The one thing that is different about Avalon from all the
other component architectures is the lookup.
The other component architectures *bind* components or component
stubs to a namespace. That namespace can be hierarchical (i.e.
use directories), or flat. EJBs and Servlets use JNDI. CORBA
uses the COS Naming Service. COM uses another mechanism (I am
not as familiar with that).
Everywhere we need to use constraints (i.e. hints), it is usually
done from a container/component. The hybrid container/component
acts as both a container and a component. Take advantage of this
fact, and access the components you need directly.
> While using java interfaces for metadata is a limited
> approach, at least it allowed stronger typing. The same can
> be said for 'role = interface'.
However, it causes problems with inheritance. Consider if you
will something that until I brought it to the Cocooners attention
was rather common. An abstract base class for component
implementations implements the ThreadSafe interface. A concrete
implementation that extends the abstract class implements the
Poolable interface. So which is it? Because of this fiasco,
we were forced to put in some checks that would throw an exception
if there were multiple LifeStyle interfaces implemented for a
component.
We were also forced to adopt the practice of not declaring lifestyle
until the component was concretely implemented. The inheritance
of lifestyle seemed like a good approach at first, but it caused
more problems than it solved.
Not to mention it is difficult to authoritatively say how the
component would be treated in the container.
That is why Fortress, Merlin, Phoenix, et. al. declare the lifestyle
and other meta information in the component descriptor. The
developer can say with confidence which creational policy (lifestyle)
was used for their component. There was less ambiguity and less
chance for inheritance causing problems.
Furthermore, with the role = interface issue in over half of the
cases it is sufficient. However, the container has no way of
knowing what the component needs in terms of external components.
By using meta data, we can implement a more *secure* system by
only allowing a component to see the external components it
needs or is registered for. As it is now, a component can freely
try interface names to attempt to control or cause internal DoS
attacks because role=interface and there is no scoping of what
the component can see.
We can develop a far more secure system that is more architecturally
unfriendly to deviant components that might be loaded in at runtime
because role != interface, and the component can only see what it
is allowed to see.
The container can have the needed control to provide a secure
environment.
>
> Anyway, since it seems like I'm the only one having such
> vision, I'll shut up and let you guys do your job.
Don't sound so defeated.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Robert Mouat wrote:
> The above example feels a little contrived -- are there any real use-cases
> when this might be needed? And will it always be obvious to the component
> that it will need a selector?
thought of one... a cocoon pipeline:
<map:pipeline>
<map:match pattern="*.html" type="wildcard">
<!-- ... -->
</map:match>
<map:match pattern="*.css" type="wildcard">
<!-- ... -->
</map:match>
</map:pipeline>
a pipeline selector could be created that took a URL and determined the
appropiate pipeline from that -- for each '<map:match/>' it could look up
the matcher and use that to compare the URL provided with the pattern.
[I think that I may have abused the term 'pipeline' above]
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Nicola Ken Barozzi wrote:
> Robert Mouat wrote:
>
> > This work is given to the assembler: who now has control of both giving
> > the transformer it's name (transformer:xslt) *and* telling the component
> > what name to lookup (transformer:xslt).
>
> Ahhhhh :-)
>
> *Now* I get it more.
>
> The "telling the component what name to lookup (transformer:xslt)." part
> I missed before.
I wasn't sure if having a client component expect this was going to break
reusuability (i.e. container independance) -- which is why I was seeking
assurances on the role of the assembler yesterday.
> Thanks. :-D
your welcome.
> Could an alternative solution be that the lookup is don on a
> TransformerManager that has a lookup(transformername) in it?
> (akin to the SocketManager example of Berin)
>
> Or is this just a recreation of a Selector?
It would be a recreation of Selector, but the selector would only need to
be used in cases that the assembler couldn't handle -- also the Selector
could be a component itself (and hence have arbitrary logic -- by which I
mean you could put *any* logic in it, not that the selection would be
arbitrary :)
I was thinking that you could create a Selector component that received in
it's configuration a set of role names and rules for when to use them.
e.g. (to borrow from a previous example) selecting a mail server based on
email address:
a MailServerSelector component could be written to take in a email address
and return a MailServar based on the address. You could use it by:
MailServerSelector mss = (MailServerSelector) cm.looup( "mail-server-selector" );
MailServer ms = mss.select( emailAddress );
the configuration for the MailServerSelector might look like:
mailserver1.roleName=apache-mail-server
mailserver1.addressRegex=*.apache.org
mailserver2.roleName=default-mail-server
mailserver2.addressRegex=*
and all the MSS would need to do is read the in rolenames and the
corresponding rules from the configuration - then when select() is called
it applies the rules until it finds one that works, then looks up the
corresponding role name from it's own CM and returns the result.
this basically takes Selector out of the framework and makes it something
that can be implemented as a component as needed.
The above example feels a little contrived -- are there any real use-cases
when this might be needed? And will it always be obvious to the component
that it will need a selector?
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Mouat wrote:
> This work is given to the assembler: who now has control of both giving
> the transformer it's name (transformer:xslt) *and* telling the component
> what name to lookup (transformer:xslt).
Ahhhhh :-)
*Now* I get it more.
The "telling the component what name to lookup (transformer:xslt)." part
I missed before.
Thanks. :-D
Could an alternative solution be that the lookup is don on a
TransformerManager that has a lookup(transformername) in it?
(akin to the SocketManager example of Berin)
Or is this just a recreation of a Selector?
Sorry if I'm pedantic, but I *really* want to understand fully what the
real implications of living without hints are.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Leo Sutic wrote:
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > lookup(role,hint);
> >
> > and
> >
> > lookup(role+"/"+hint);
>
> FWIW, I'm very pro-lookup(role,hint);
both role,hint and role/hint may be unnecessary...
Assumption: any resolution of role+hint (or role,hint or role/hint) that a
container can be reasonably expected to do, the assembler can also be
expected to do.
[i.e. if a hint is generated at runtime, and requires runtime resolution
then it is probably beyond the scope of the container -- and should be
resolved by a specialised ComponentSelector component]
Claim: a component doesn't need lookup(role,hint), and doesn't need to do
any string concatenation implied by lookup(role+"/"+hint) -- i.e.
lookup(role) should be enough.
Basically, the work gets shifted to the assembler. The assembler does the
resolution (at assembly time), determines an unambiguous role name for the
component to be lookup up, and passes this role name onto the client
component via it's configuration.
e.g. given a cocoon site map containing:
[appologies in advance for not being very familiar with cocoon]
<map:transformers default="xslt">
<map:transformer name="xslt" src="org.apache.cocoon.transformation.TraxTransformer"/>
<map:transformer name="xinclude" src="org.apache.cocoon.transformation.XIncludeTransformer"/>
</map:transformers>
and
<map:match pattern="*.html">
<map:generate src="xdocs/{1}.xml"/>
<map:transform type="xinclude"/>
<map:transform src="stylesheets/xml2html.xsl"/>
<map:serialize/>
</map:match>
the assembler [code that compiles the sitemap] could:
- create components with role names transformer:xslt and transformer:xinclude
- pass these role names into the pipeline's configuration e.g. something
equivalent to:
transformer1.roleName=transformer:xslt
transformer2.roleName=transformer:xinclude
[or, more precisely, tell the container to do this]
Then when the component wants to lookup the first transformer it fetches
the role name from it's configuration and passes the result to lookup().
So now the component doesn't need to do string concatenation and the
component locater doesn't need to check for string concatenation (i.e.
search the role name for the "/" character to determine if a hint was
used)
This work is given to the assembler: who now has control of both giving
the transformer it's name (transformer:xslt) *and* telling the component
what name to lookup (transformer:xslt). (note: the assembler could have
chosen "asdfghjkl" as the role name if it desired [though this might
make log files confusing :)]).
I think this approach looks a little nicer that role+"/"+hint -- and while
potentially not as powerful as role,hint (in the case of runtime data), it
makes it clear exactly what is going to happen.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> lookup(role,hint);
>
> and
>
> lookup(role+"/"+hint);
FWIW, I'm very pro-lookup(role,hint);
> While using java interfaces for metadata is a limited
> approach, at least it allowed stronger typing. The same can
> be said for 'role = interface'.
Yes, but the price (namespace conflicts) is too high.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stefano Mazzocchi <st...@apache.org>.
Playing the stubborn role at least brought some unification back, which
is a good thing, no matter how much my ego is satisfied with the
resoluzion :)
> What you are accusing Peter and company of doing is not really
> any different than what Cocoon does. The lookup might change
> from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
> but the general outcome is the same. There is *essentially*
> ten different roles if we are being true to what it conceptually
> is.
I've been stating this forever but I repeat: I *know* that what Peter
proposes is functionally equivalent. The problem is that I don't
resonate with the approach choosen.
> To the pipeline, A generator is a generator is a generator.
> To the sitemap, we may have ten different implementations that
> we choose from. The *sitemap* chooses which of those 10
> generators are used depending on context. Because it is a
> container in and of itself, it can do so in any way it chooses.
> Effectively each individual Generator performs a different role.
> One pulls info from the filesystem, another pulls it from an
> external site, and yet another will pull it from a database.
> The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
> directly request the generator. The sitemap sets the generator.
>
> So for real practicality's sake, we either have a distinct
> role for each of the Generators or we have a smart container.
>
> Think of it in terms of the Chorus in a theatrical play. They
> act as one, but they have their own part to play in the harmony
> or narration of the play. There might be three distinct people
> on the stage at one time that perform the same general function.
> It is the same with the concept of generators in Cocoon.
>
> Please tell me if I have confused you more than I have clarified
> things.
No, it is clear now and it was clear before, just that I do not perceive
lookup(role,hint);
and
lookup(role+"/"+hint);
to be architectrually equivalent since they represent two different
cognitive ways to access to components and we loose completely the
ability to match a role to a java interface.
While using java interfaces for metadata is a limited approach, at least
it allowed stronger typing. The same can be said for 'role = interface'.
Anyway, since it seems like I'm the only one having such vision, I'll
shut up and let you guys do your job.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> ie if Client specifies they MUST use SSL enabled ConnManager then it is likely
> because they do something like
>
> final SSLSocket sslSocket = (SSLSocket)myConnMann.getSocket(...);
> sslSocket.setClientCerts( myCertificates );
myConnMann.getSocket ?
where's .lookup?
Also:
final Socket sslSocket = (Socket)myConnMann.getSocket(...);
> If the constraint is not enforced then the application will fail when
> executing - precisely what we want to avoid by tagging dependency with
> constraints.
If you specify these constraits *outside* of the caller, how can the
caller do a dynamic lookup?!?
> ie Don't confuse constraints and hints/policys. hints/policys just suggest
> good characteristerics of the provider but need not be enforced.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> > This would mean (Cocoon example) that the cm would not give you a
> > Transformer or a Generator, but a service that manages them.
>
> Depends on interface of Generator. If it is a resource then yes, if it is a
> service then no. It sounds like Generator has been made a resource (really
> bad move IMHO) and thus you do need a GeneratorManager. Personally I would
> have made it a service.
I see a 'pipeline' being a service, but not its constructive components
(which are resources).
Why? the SAX event-driven architecture! when we had DOM it could have
been possible to do:
document = generatingService.generate('file', src, objectModel);
document = transformingService.transform('xslt', src, objectModel);
...
serializeService.serialize('html',document,output);
but with a SAX architecture, you have to 'assemble' the pipeline (which
is the real service) *before* you can call the service.
This is why I think it's still the best solution to architecturally
consider pipeline 'pieces' as resources (objects) and not services
(method handlers).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> At 08:21 AM 6/27/2002 +0200, you wrote:
>
>>>> This would mean (Cocoon example) that the cm would not give you a
>>>> Transformer or a Generator, but a service that manages them.
>>>
>>> Depends on interface of Generator. If it is a resource then yes, if
>>> it is a service then no. It sounds like Generator has been made a
>>> resource (really bad move IMHO) and thus you do need a
>>> GeneratorManager. Personally I would have made it a service.
>>
>>
>> Hmmm... Isn't the GeneratorManager the service for the Generator?
>> I guess not, since I'm asking objects (ie Generators) to it, not
>> making it generate(), right?
>
>
> yep
>
>> Making it a service could mean setting the Generator type and calling
>> generate() on the service, so I don't even have to get an object from
>> it, which is worse.
>
>
> Thats one way of doing it. However I would tend to pass in the type to
> the method.
Which means that it's stateless in itself! :-)
> Now the callers of GeneratorService don't even have to know
> that there is such an interface as Generator and it becomes an
> implementation detail you are free to change in future. Kool huh.
Well, instead of Generator we have GeneratorService, but the difference
is that Generator is used all over the place, while the service is
just... well... the service :-)
Hey, this is good encapsulation!
>> I have understood some time age (though I'm not so good a doing yet)
>> that to encapsulate well and reduce roundtripping madness you should
>> always call methods on objects, not request other objects.
>> Using a GeneratorService would make this possible, right?
>
> Largely and the clients would not need to know whether the Generator is
> pooled, un-pooled, clustered, distributed or anything else. All they
> know is that they call method X with parameters Y to get a service. Zero
> resource management on their side. Yea yea yea!
Gee, Peter, thanks!
Now I think I'm getting excited ;-)
If others will agree (let's see) it could be that changing the way
Cocoon works would really help Avalon, since it's a big example of how
(not?) to use components (anyone here please correct me, it's my
excitement that makes me say mad things ;-).
Could we generally say (I think so) that a good service should be:
1. stateless
2. encapsulate implementations, which doesn't only have to be an
interface, but also (important) an interface that is not used in the
framework, ie it must only be a... service ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for
'hints')
Posted by Peter Donald <pe...@apache.org>.
At 08:21 AM 6/27/2002 +0200, you wrote:
>>>This would mean (Cocoon example) that the cm would not give you a
>>>Transformer or a Generator, but a service that manages them.
>>Depends on interface of Generator. If it is a resource then yes, if it is
>>a service then no. It sounds like Generator has been made a resource
>>(really bad move IMHO) and thus you do need a GeneratorManager.
>>Personally I would have made it a service.
>
>Hmmm... Isn't the GeneratorManager the service for the Generator?
>I guess not, since I'm asking objects (ie Generators) to it, not making it
>generate(), right?
yep
>Making it a service could mean setting the Generator type and calling
>generate() on the service, so I don't even have to get an object from it,
>which is worse.
Thats one way of doing it. However I would tend to pass in the type to the
method. Now the callers of GeneratorService don't even have to know that
there is such an interface as Generator and it becomes an implementation
detail you are free to change in future. Kool huh.
>I have understood some time age (though I'm not so good a doing yet) that
>to encapsulate well and reduce roundtripping madness you should always
>call methods on objects, not request other objects.
>Using a GeneratorService would make this possible, right?
Largely and the clients would not need to know whether the Generator is
pooled, un-pooled, clustered, distributed or anything else. All they know
is that they call method X with parameters Y to get a service. Zero
resource management on their side. Yea yea yea!
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 26 Jun 2002 19:24, Nicola Ken Barozzi wrote:
>
>>>Then your program wont scale, will be hell to maintain and suffer from
>>>pattern hell. Self induced aswell - you don't honestly expect me to feel
>>>sorry for you do you? :)
>>
>>;-) hehehe
>>
>>Let me see if I understand.
>>
>>ComponentManager should give you course grained components.
>
>
> Coarseness is not the main requirement for being accessible from CM. For
> instance in myrmidon we have components that just validate a name and that
> qualifies as a component (maybe 20 lines if that). The main requirement is
> that the object be a service NOT a resource.
>
> Ie it is perfectly valid to nab a DataSource from the SM but if you grabbed a
> JDBC Connection you are just inviting pain and user confusion.
>
> * Will multiple lookups produce same resource or new resources each time or do
> something completely different
> * When are resources released
> * what does it mean if you hold the resource
> * you have to explicitly worry about which components are resources and which
> are services to make sure you micro-manage their usage patterns
> * etc
Ok, I think I understand.
Thank you for this explanation :-)
>>This would mean (Cocoon example) that the cm would not give you a
>>Transformer or a Generator, but a service that manages them.
>
> Depends on interface of Generator. If it is a resource then yes, if it is a
> service then no. It sounds like Generator has been made a resource (really
> bad move IMHO) and thus you do need a GeneratorManager. Personally I would
> have made it a service.
Hmmm... Isn't the GeneratorManager the service for the Generator?
I guess not, since I'm asking objects (ie Generators) to it, not making
it generate(), right?
Making it a service could mean setting the Generator type and calling
generate() on the service, so I don't even have to get an object from
it, which is worse.
I have understood some time age (though I'm not so good a doing yet)
that to encapsulate well and reduce roundtripping madness you should
always call methods on objects, not request other objects.
Using a GeneratorService would make this possible, right?
>>Let me say anyway that I don't particularly like the fact that a
>>developer has to write a Manager,
>
> Thanks - I didn't hear it the first 5 or 6 times you said it.
Oh, sorry.
Anyway, just to be clear, I don't particularly like the fact that a
>>developer has to write a Manager ;-P
>>but I suppose that this is what
>>ContainerKit is for?
>
> not really. ContainerKit is for building containers not reosurce managers.
>
> In the end if you don't want to write a custom manager then don't. Just
> remember that I told you it wont scale when you start running into problems.
Now that I think I understood more I will write my Manager now ;-)
Even if I think that this could be seen as a complication from users, dunno.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Donald <pe...@apache.org>.
On Wed, 26 Jun 2002 19:24, Nicola Ken Barozzi wrote:
> > Then your program wont scale, will be hell to maintain and suffer from
> > pattern hell. Self induced aswell - you don't honestly expect me to feel
> > sorry for you do you? :)
>
> ;-) hehehe
>
> Let me see if I understand.
>
> ComponentManager should give you course grained components.
Coarseness is not the main requirement for being accessible from CM. For
instance in myrmidon we have components that just validate a name and that
qualifies as a component (maybe 20 lines if that). The main requirement is
that the object be a service NOT a resource.
Ie it is perfectly valid to nab a DataSource from the SM but if you grabbed a
JDBC Connection you are just inviting pain and user confusion.
* Will multiple lookups produce same resource or new resources each time or do
something completely different
* When are resources released
* what does it mean if you hold the resource
* you have to explicitly worry about which components are resources and which
are services to make sure you micro-manage their usage patterns
* etc
> This would mean (Cocoon example) that the cm would not give you a
> Transformer or a Generator, but a service that manages them.
Depends on interface of Generator. If it is a resource then yes, if it is a
service then no. It sounds like Generator has been made a resource (really
bad move IMHO) and thus you do need a GeneratorManager. Personally I would
have made it a service.
> Let me say anyway that I don't particularly like the fact that a
> developer has to write a Manager,
Thanks - I didn't hear it the first 5 or 6 times you said it.
> but I suppose that this is what
> ContainerKit is for?
not really. ContainerKit is for building containers not reosurce managers.
In the end if you don't want to write a custom manager then don't. Just
remember that I told you it wont scale when you start running into problems.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 26 Jun 2002 17:08, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>On Wed, 26 Jun 2002 16:26, Nicola Ken Barozzi wrote:
>>>
>>>>Peter Donald wrote:
>>>>
>>>>>It really comes down to what the component writer wants to classify as a
>>>>>constraint and what they want to classify as a hint/policy. The
>>>>>component writer could choose to make "secure" a constraint or they
>>>>>could choose to make it a hint.
>>>>
>>>>Peter, what you say makes sense, but how the f**k can you make the client
>>>>specify a hint||constraint with
>>>>
>>>> SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
>>>>
>>>>?!?!?!?!?!?
>>>
>>>ummm ... metadata?
>>
>>Me no understand.
>>Me need to see code. Example.
>>Please help poor programmer.
>
>
> It is no different from any of the other example I have given so go read the
> archives.
I looked at them again, but didn't find the answers I need.
<begging-mode>Please give me a link or some key words</begging-mode>
>>>BTW there is not a chance that I would suggest that you directly extract
>>>a resource directly from a ComponentManager. That would suck
>>>unbelievably, would never scale and lead to all sorts of design
>>>compromises. You aquire a SocketManager who does the work.
>>
>>?
>>
>>If my component is Composable, I get a ComponentManager, not a
>>SocketManager.
>>I don't want to make a SocketManager.
>>I want to use a pre-built Manager.
>
>
> Then your program wont scale, will be hell to maintain and suffer from pattern
> hell. Self induced aswell - you don't honestly expect me to feel sorry for
> you do you? :)
;-) hehehe
Let me see if I understand.
ComponentManager should give you course grained components.
This means that a simple lookup is always enough.
This is more easily understood if we think of Blocks or services.
This would mean (Cocoon example) that the cm would not give you a
Transformer or a Generator, but a service that manages them.
This service would have his own logic of query and selection; it's more
near to implementations and has more knowledge of how it all works.
Is this it?
Let me say anyway that I don't particularly like the fact that a
developer has to write a Manager, but I suppose that this is what
ContainerKit is for?
>>Do I have to pay you to get example in code or are you gonna enlighten
>>me for free if I whine enough?
>
>
> What has been wrong with any of the other code examples?
<doing action="banging head on the wall">Don't find 'em :-(</doing>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Donald <pe...@apache.org>.
On Wed, 26 Jun 2002 17:08, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > On Wed, 26 Jun 2002 16:26, Nicola Ken Barozzi wrote:
> >>Peter Donald wrote:
> >>>It really comes down to what the component writer wants to classify as a
> >>>constraint and what they want to classify as a hint/policy. The
> >>> component writer could choose to make "secure" a constraint or they
> >>> could choose to make it a hint.
> >>
> >>Peter, what you say makes sense, but how the f**k can you make the client
> >>specify a hint||constraint with
> >>
> >> SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
> >>
> >>?!?!?!?!?!?
> >
> > ummm ... metadata?
>
> Me no understand.
> Me need to see code. Example.
> Please help poor programmer.
It is no different from any of the other example I have given so go read the
archives.
> > BTW there is not a chance that I would suggest that you directly extract
> > a resource directly from a ComponentManager. That would suck
> > unbelievably, would never scale and lead to all sorts of design
> > compromises. You aquire a SocketManager who does the work.
>
> ?
>
> If my component is Composable, I get a ComponentManager, not a
> SocketManager.
> I don't want to make a SocketManager.
> I want to use a pre-built Manager.
Then your program wont scale, will be hell to maintain and suffer from pattern
hell. Self induced aswell - you don't honestly expect me to feel sorry for
you do you? :)
> Do I have to pay you to get example in code or are you gonna enlighten
> me for free if I whine enough?
What has been wrong with any of the other code examples?
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Peter Royal wrote:
>>It would seem logical that there are *exact* anti-patterns to watch for
>>that would prescribe the use of COP over OOP, and visa versa.
>>
>>
>There are. On a whim I changed the topic on #avalon on irc.whichever.com:6667
>(where the turbine guys hang out and jvz summons me for questioning) to "how
>components can change your life in 10 easy steps".. I think it would be an
>interesting document to create.
>
>>It would also seem logical that these should be the top of everyone's
>>list to know and rattle off. Without these, we are just messing around
>>with fun stuff for the sake of messing around.
>>
>>
>I like messing around. I'm here because I enjoy it and its a lot of fun to
>read the interactions and knowledge that flows back and forth :)
>-pete
>
As close to a bogus answer as you could give, and still tell the truth.
Of the many things you could be accused of, messing around is not one of
them, and I mean that as a compliment.
So what are the top anti-patterns. What are the top benefits? Hold back
no longer !
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 26 June 2002 06:52 pm, Pete Carapetyan wrote:
> It would seem logical that there are *exact* anti-patterns to watch for
> that would prescribe the use of COP over OOP, and visa versa.
There are. On a whim I changed the topic on #avalon on irc.whichever.com:6667
(where the turbine guys hang out and jvz summons me for questioning) to "how
components can change your life in 10 easy steps".. I think it would be an
interesting document to create.
> It would also seem logical that these should be the top of everyone's
> list to know and rattle off. Without these, we are just messing around
> with fun stuff for the sake of messing around.
I like messing around. I'm here because I enjoy it and its a lot of fun to
read the interactions and knowledge that flows back and forth :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Peter Royal wrote:
>On Wednesday 26 June 2002 10:27 am, Nicola Ken Barozzi wrote:
>
>
>>I think there is something plain confusing in all this.
>>
>>
>
>"one man's component is another man's object"
>:)
>
>There are no "hard and fast" rules, its all a design decision. Making
>everything a component would be overkill (the hammer anti-pattern!). One has
>to decide the proper level of component abstraction for their own projects.
>
Just for the sake of argument, I would propose that you are exactly
right about the hammer analogy, but just glossing over it misses the
point, Peter.
It would seem logical that there are *exact* anti-patterns to watch for
that would prescribe the use of COP over OOP, and visa versa.
It would also seem logical that these should be the top of everyone's
list to know and rattle off. Without these, we are just messing around
with fun stuff for the sake of messing around.
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 26 June 2002 10:27 am, Nicola Ken Barozzi wrote:
> I think there is something plain confusing in all this.
"one man's component is another man's object"
:)
There are no "hard and fast" rules, its all a design decision. Making
everything a component would be overkill (the hammer anti-pattern!). One has
to decide the proper level of component abstraction for their own projects.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>>>Your definition of Component is too flimsy.
>>>>Give me a set of rules, and let's stick to that.
>>>
>>>
>>>I could write a book on the subject (oh, yeah...).
>>>
>>>Let's just say that I am not going to put 20+
>>>pages of spoilers on the list. You'll just have to
>>>be patient. What I gave you is what the component
>>>community can agree upon.
>>
>>Which is nothing ;-)
>>
>>Seriously, what about Cocoon using Serializers, Transformers,
>>etc as Components. Aren't they "information"?
>
>
> No. The XML or SAX stream is the information.
Then a Socket is not information.
The stream is.
A socket is an information endpoint, as Generators are with XML.
> They represent different stages of how to create or manipulate
> that information. They also provide a nice abstraction so that
> you can easily understand how they relate to each other.
I agree, only that I don't understand why a Socket is information.
A Socket is an abstraction, you don't have sockets in your cabinet, do
you? ;-P
>>You wrote:
>> > Again, you have to have the proper abstraction.
>> > In this case,
>> > the Socket itself is the *wrong* abstraction.
>> > The container
>> > should not make up for your poor design habits.
>>
>>I this Berin or Peter Donald :-?
>
>
> I am in the process of refactoring software that was clearly not
> designed. It mixes OO and procedural concepts providing an
> incomprehensible mush.
>
> I *really* hate bad/no design.
Yeah, I feel your pain, brother.
>>Ok, se let's call it MyAbstractConnectionEndpoint.
>>And have Socket, MYSocket, WoolThreadEndpoint implement it.
>>
>>Would it be a Component, given the above premises?
>>
>>I think there is something plain confusing in all this.
>
> :)
>
> It would satisfy the technical requirements for being a component.
Ok, then it is.
A bad component? Maybe.
But a component nevertheless.
> But what does it do?
>
> Think of your system as a play. You have actors that perform.
> They have a set script, contracts so to speak. Whether it is
> Mel Gibson or Mark Hammel (I prefer Mel) playing Hamlet, the
> performance goes through the same mechanical aspects of the
> script. The performance is quite different, but the end effect
> is the same.
>
> Remember that actors interact with their surroundings. Unless
> you are watching mime or some avante guard neo classical crap
> they interact with props. Props can be just as important as
> the actor, esp. in murder mysteries.
>
> Try to break down your components like you would have actors
> tell a story. The story in this case is what your system does.
> If you want your system to be like a Saturday morning cartoon,
> then having animated props (like a talking blanket) is appropriate.
> However, don't complain to me if your Saturday morning cartoon
> doesn't scale up to the big screen.
:-))
> That is the general rule of thumb, and why we refer to components
> by their "Role".
Every system can be analysed at different levels, and this "play"
metaphore yields different results with different levels.
This is what makes it so difficult IMHO.
It seems that Avalon is geared towards coarse grained components, and as
time goes by I'm more and more confident of this.
That's why I didn't make Tweety itself a Component in the first place BTW.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Berin Loritsch wrote:
> >>Your definition of Component is too flimsy.
> >>Give me a set of rules, and let's stick to that.
> >
> >
> > I could write a book on the subject (oh, yeah...).
> >
> > Let's just say that I am not going to put 20+
> > pages of spoilers on the list. You'll just have to
> > be patient. What I gave you is what the component
> > community can agree upon.
>
> Which is nothing ;-)
>
> Seriously, what about Cocoon using Serializers, Transformers,
> etc as Components. Aren't they "information"?
No. The XML or SAX stream is the information.
They represent different stages of how to create or manipulate
that information. They also provide a nice abstraction so that
you can easily understand how they relate to each other.
> You wrote:
> > Again, you have to have the proper abstraction.
> > In this case,
> > the Socket itself is the *wrong* abstraction.
> > The container
> > should not make up for your poor design habits.
>
> I this Berin or Peter Donald :-?
I am in the process of refactoring software that was clearly not
designed. It mixes OO and procedural concepts providing an
incomprehensible mush.
I *really* hate bad/no design.
> Ok, se let's call it MyAbstractConnectionEndpoint.
> And have Socket, MYSocket, WoolThreadEndpoint implement it.
>
> Would it be a Component, given the above premises?
>
> I think there is something plain confusing in all this.
:)
It would satisfy the technical requirements for being a component.
But what does it do?
Think of your system as a play. You have actors that perform.
They have a set script, contracts so to speak. Whether it is
Mel Gibson or Mark Hammel (I prefer Mel) playing Hamlet, the
performance goes through the same mechanical aspects of the
script. The performance is quite different, but the end effect
is the same.
Remember that actors interact with their surroundings. Unless
you are watching mime or some avante guard neo classical crap
they interact with props. Props can be just as important as
the actor, esp. in murder mysteries.
Try to break down your components like you would have actors
tell a story. The story in this case is what your system does.
If you want your system to be like a Saturday morning cartoon,
then having animated props (like a talking blanket) is appropriate.
However, don't complain to me if your Saturday morning cartoon
doesn't scale up to the big screen.
That is the general rule of thumb, and why we refer to components
by their "Role".
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>Your definition of Component is too flimsy.
>>Give me a set of rules, and let's stick to that.
>
>
> I could write a book on the subject (oh, yeah...).
>
> Let's just say that I am not going to put 20+
> pages of spoilers on the list. You'll just have to
> be patient. What I gave you is what the component
> community can agree upon.
Which is nothing ;-)
Seriously, what about Cocoon using Serializers, Transformers,
etc as Components.
Aren't they "information"?
Any rule that is not enforcible or easily explainable is a bad rule.
What's the rule for a Component?
1) Separate interface from implementation
Easy to do, even with Sockets ie Socket implements Endpoint
2) No argument public constructor
Easy here too
3) Distributed in binary form (aka jar file)
Plain easy.
In Avalon, I would add: "is treated following the lifecycle rules"
You wrote:
> Again, you have to have the proper abstraction.
> In this case,
> the Socket itself is the *wrong* abstraction.
> The container
> should not make up for your poor design habits.
I this Berin or Peter Donald :-?
Ok, se let's call it MyAbstractConnectionEndpoint.
And have Socket, MYSocket, WoolThreadEndpoint implement it.
Would it be a Component, given the above premises?
I think there is something plain confusing in all this.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> Your definition of Component is too flimsy.
> Give me a set of rules, and let's stick to that.
I could write a book on the subject (oh, yeah...).
Let's just say that I am not going to put 20+
pages of spoilers on the list. You'll just have to
be patient. What I gave you is what the component
community can agree upon.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>
>>This is exactly the point.
>>I'm used to requesting components, not managers.
>>It's in the name: ComponentLocator, not ComponentManagerLocator.
>
>
> Nicola, your problem is in your loose definition of component.
> Not all objects are components. The SocketManager is a component.
> The Socket is an object.
>
> *ALL* components have the following attributes:
>
> 1) Separate interface from implementation (Socket fails here)
?
Conceptually if it was:
MySocket implements Socket
SSLSocket implements Socket
> 2) No argument public constructor
>
> 3) Distributed in binary form (aka jar file)
I'm not using Socket as a JDK class but as a concept.
All the above can be done.
> *GOOD* components have the following going for them:
>
> 1) Represent logic or service--not information
>
> 2) Proper abstraction so as not to force implementation details
> and remain easy to use.
>
>
> A Socket is a type of information. It represents a way to
> communicate with the outside world.
I don't really get this, it seems really too abstract to grasp.
With your definition, a Component is an object manager.
Then what's a ComponentManager? A manager of managers of objects?
:-S
> It does not make a component, much less a good component. You
> would have to have a new "component" for each location you want
> to connect to. A SocketManager gives you one point of access
> and lets you connect to any external server--and provides the
> ability to enforce sitewide security constraints over which
> servers the sytem is able to connect with. Something you would
> not be able to do with your previous approach.
>
> If you don't want to write a SocketManager, use someone else's.
> This is COP, and you aren't the only one writing components.
Yeah, sure. I wanted to use Avalon's :-P
> The one thing that gets to me is the overuse of the word component.
> Commons is the most guilty party of this confustion.
>
> This formula should clear things up:
>
> API != Component
Your definition of Component is too flimsy.
Give me a set of rules, and let's stick to that.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 26 June 2002 09:45 am, Leo Sutic wrote:
> Berin, you can argue endlessly that a socket isn't a component,
> or what makes a component. Point is this:
>
> + There will always be something that fulfills your every
> requirement for a component but that must still be pooled.
>
> + We do not want to write a separate manager for each one of
> those. No matter how much that fits your view of good
> architecture. *It is not practical.*
>
> Can you convince us that you have a better solution than
> what exists now, or that we for some reason do not want the
> container to handle the pooling, do so.
>
> The arguments we have had regarding that would indicate
> that no such solution exists.
The real question:
* Should a user of a component have to be aware of whether or not a component
is pooled *
Since thats a yes/no question, we have two answers:
NO: We *must* stay with transparent pooling in the container. No way to remove
CM.release()
YES: We can create a generic PoolableComponentManager that looks something
like this:
interface PoolableComponentManager
{
Object get();
void release( Object o );
}
Which would then negate the need for discrete managers for each component
type.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 26 juni 2002 16:02
> To: 'Leo Sutic'; 'Avalon Developers List'
> Subject: RE: Fresh Outlook: (was RE: [desperate plea] RE: The
> need for 'hints')
>
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > Nicola, your problem is in your loose definition of
> component. Not
> > > all objects are components. The SocketManager is a
> component. The
> > > Socket is an object.
> > >
> > > *ALL* components have the following attributes:
> > >
> > > 1) Separate interface from implementation (Socket fails here)
> > >
> > > 2) No argument public constructor
> > >
> > > 3) Distributed in binary form (aka jar file)
> >
> > So if I come up with a general Socket interface, we're good
> to go with
> > Socket as component?
> >
> > Didn't think so.
> >
> > Berin, you can argue endlessly that a socket isn't a
> > component, or what makes a component. Point is this:
> >
> > + There will always be something that fulfills your every
> > requirement for a component but that must still be pooled.
>
> Leo, Who said this was about pooling? This is not about pooling.
There is a connection, but I should have spelled it out:
+ Because the architecture you advocate implies no transparent pooling
done by the container. (Everything you look up is thread safe.)
+ Because this issue is always linked to the use case when we have
components that should be pooled.
(Unclear, I realize.)
> The concept of representing your information as
> psuedo-components (I refuse to give them the honor of full
> component status) does not scale because you are forced into
> one way of doing things, and you are requiring the container
> to make up for your lack of design. Those things are bad.
Berin, your explanation for why it does not scale is a
non-explanation. It does not scale because
+ I'm forced into one way of doing things
+ I'm requiring the container to make up for my lack of design
?
Either of these two, with actually only the first being even
remotely similar to an explanation, does not explain why
it won't scale.
*The only time one way of doing things is the wrong way is
when that way _in itself_ does not scale.* So you can not say
that because I do things one way, it won't scale. You have to
say "Because that way means you can not do this this and this."
So, to distill it to basics: Why will it not scale, if I let
Sockets be Components?
> What happens if you want to change the persistence mechanism?
> What happens if you want to change the way security is enforced?
I see security policies as something entirely orthogonal to whether
or not a Socket is a component (which is the practical case we started
with).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Nicola, your problem is in your loose definition of
> > component. Not all objects are components. The SocketManager
> > is a component. The Socket is an object.
> >
> > *ALL* components have the following attributes:
> >
> > 1) Separate interface from implementation (Socket fails here)
> >
> > 2) No argument public constructor
> >
> > 3) Distributed in binary form (aka jar file)
>
> So if I come up with a general Socket interface, we're good
> to go with Socket as component?
>
> Didn't think so.
>
> Berin, you can argue endlessly that a socket isn't a
> component, or what makes a component. Point is this:
>
> + There will always be something that fulfills your every
> requirement for a component but that must still be pooled.
Leo, Who said this was about pooling? This is not about
pooling.
> + We do not want to write a separate manager for each one of
> those. No matter how much that fits your view of good
> architecture. *It is not practical.*
Again, you have to have the proper abstraction. In this case,
the Socket itself is the *wrong* abstraction. The container
should not make up for your poor design habits.
Also, don't forget you are not the only one writing components.
Someone else will come up with an abstraction that works in
multiple environments.
> Can you convince us that you have a better solution than
> what exists now, or that we for some reason do not want the
> container to handle the pooling, do so.
I repeat. THIS CONVERSATION IS NOT ABOUT POOLING. Please
do not confuse the issues. WE ARE NOT ADDRESSING POOLING.
We are addressing ABSTRACTION.
> The arguments we have had regarding that would indicate
> that no such solution exists.
Let me ask you. In this instance, would you implement information
as a component, or would you provide an abstraction to get
the information?
Let's leave the socket alone for the moment. In Avalon, it is
not the container's responsibility to obtain the information
from the persistence mechanism, nor to validate it is the exact
information you need. It is also not the container's responsibility
to determine if the calling user is permitted to see that
information.
All of that should be provided in an abstraction that takes care
of all those points for you. Done correctly, the abstraction
can be generic enough to work for many different types of
information--increasing its usefulness.
The concept of representing your information as psuedo-components
(I refuse to give them the honor of full component status) does
not scale because you are forced into one way of doing things,
and you are requiring the container to make up for your lack of
design. Those things are bad.
Even in EJB Entity Bean design, you have a Home interface that
allows you to get a particular instance of the entity bean. That
home interface is the level of abstraction that I am advocating.
You should specify *HOW* to get your information, not *WHAT* the
information is. It would be even better if all your components
were like stateless session beans--but we know that is not always
practical.
What happens if you want to change the persistence mechanism?
What happens if you want to change the way security is enforced?
When you represent your information as components, you have to
change the *same* logic in several locations--even if you use
an external component to do the actual persistence management.
If you have one interface to get at your information, you can
change it in one place and everything is happy.
Information is practically just at too fine a detail for the
design to scale properly. Worse, designs centered around information
rather than who works with the information are harder to
comprehend, and have more points of failure.
This has nothing to do with pooling.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Nicola, your problem is in your loose definition of
> component. Not all objects are components. The SocketManager
> is a component. The Socket is an object.
>
> *ALL* components have the following attributes:
>
> 1) Separate interface from implementation (Socket fails here)
>
> 2) No argument public constructor
>
> 3) Distributed in binary form (aka jar file)
So if I come up with a general Socket interface, we're good
to go with Socket as component?
Didn't think so.
Berin, you can argue endlessly that a socket isn't a component,
or what makes a component. Point is this:
+ There will always be something that fulfills your every
requirement for a component but that must still be pooled.
+ We do not want to write a separate manager for each one of
those. No matter how much that fits your view of good
architecture. *It is not practical.*
Can you convince us that you have a better solution than
what exists now, or that we for some reason do not want the
container to handle the pooling, do so.
The arguments we have had regarding that would indicate
that no such solution exists.
As for the reason one would not want to implement pooling that way,
I have repeatedly asked for a justification of the claims that
"it does not scale" etc.:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335077401400&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335398303810&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335214102411&w=2
but the absence of an answer indicates that no such reason exists
either.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
>
> This is exactly the point.
> I'm used to requesting components, not managers.
> It's in the name: ComponentLocator, not ComponentManagerLocator.
Nicola, your problem is in your loose definition of component.
Not all objects are components. The SocketManager is a component.
The Socket is an object.
*ALL* components have the following attributes:
1) Separate interface from implementation (Socket fails here)
2) No argument public constructor
3) Distributed in binary form (aka jar file)
*GOOD* components have the following going for them:
1) Represent logic or service--not information
2) Proper abstraction so as not to force implementation details
and remain easy to use.
A Socket is a type of information. It represents a way to
communicate with the outside world.
It does not make a component, much less a good component. You
would have to have a new "component" for each location you want
to connect to. A SocketManager gives you one point of access
and lets you connect to any external server--and provides the
ability to enforce sitewide security constraints over which
servers the sytem is able to connect with. Something you would
not be able to do with your previous approach.
If you don't want to write a SocketManager, use someone else's.
This is COP, and you aren't the only one writing components.
The one thing that gets to me is the overuse of the word component.
Commons is the most guilty party of this confustion.
This formula should clear things up:
API != Component
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>>BTW there is not a chance that I would suggest that you directly
>>>extract a
>>>resource directly from a ComponentManager. That would suck
>>
>>unbelievably,
>>
>>>would never scale and lead to all sorts of design
>>
>>compromises. You aquire a
>>
>>>SocketManager who does the work.
>>
>>?
>>
>>If my component is Composable, I get a ComponentManager, not a
>>SocketManager.
>>I don't want to make a SocketManager.
>>I want to use a pre-built Manager.
>
>
>
> Nicola, that is Peter's point.
>
> Your example of
>
> Socket sock = (Socket) cm.lookup("SSL");
>
> was flawed.
>
> The ComponentManager/ComponentLocater returns a SocketManager or
> something along those lines. Therefore, the proper example would
> be:
>
> SocketManager sm = (SocketManager) cm.lookup("sockets");
> Socket sock = sm.getSSLSocket();
>
> Or something of that nature.
This is exactly the point.
I'm used to requesting components, not managers.
It's in the name: ComponentLocator, not ComponentManagerLocator.
Not that I mean that any of the two is better, personally it's the same,
but maybeI don't fully understand, because the the SocketManager looks
like a Selector...
Or does it mean that it's just container chaining/hierarchy?
If it's a hierarchy, then the Selector is basically a single simple
child componentmanager, as hints are single simple metadata.
Is this correct?
But then, is it correct that lookup(xxx) gives me a manager or a
component? I thought that this was not nice, but maybe I didn't get the
issue.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > BTW there is not a chance that I would suggest that you directly
> > extract a
> > resource directly from a ComponentManager. That would suck
> unbelievably,
> > would never scale and lead to all sorts of design
> compromises. You aquire a
> > SocketManager who does the work.
>
> ?
>
> If my component is Composable, I get a ComponentManager, not a
> SocketManager.
> I don't want to make a SocketManager.
> I want to use a pre-built Manager.
Nicola, that is Peter's point.
Your example of
Socket sock = (Socket) cm.lookup("SSL");
was flawed.
The ComponentManager/ComponentLocater returns a SocketManager or
something along those lines. Therefore, the proper example would
be:
SocketManager sm = (SocketManager) cm.lookup("sockets");
Socket sock = sm.getSSLSocket();
Or something of that nature.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 26 Jun 2002 16:26, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>It really comes down to what the component writer wants to classify as a
>>>constraint and what they want to classify as a hint/policy. The component
>>>writer could choose to make "secure" a constraint or they could choose to
>>>make it a hint.
>>
>>Peter, what you say makes sense, but how the f**k can you make the client
>>specify a hint||constraint with
>>
>> SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
>>
>>?!?!?!?!?!?
>
>
> ummm ... metadata?
Me no understand.
Me need to see code. Example.
Please help poor programmer.
> BTW there is not a chance that I would suggest that you directly extract a
> resource directly from a ComponentManager. That would suck unbelievably,
> would never scale and lead to all sorts of design compromises. You aquire a
> SocketManager who does the work.
?
If my component is Composable, I get a ComponentManager, not a
SocketManager.
I don't want to make a SocketManager.
I want to use a pre-built Manager.
Do I have to pay you to get example in code or are you gonna enlighten
me for free if I whine enough?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Change the Abstraction (was RE: Fresh Outlook:)
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> >
> > Peter, what you say makes sense, but how the f**k can you make the
> > client specify a hint||constraint with
> >
> > SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
> >
> > ?!?!?!?!?!?
>
> ummm ... metadata?
Which is what we've been saying.
> BTW there is not a chance that I would suggest that you
> directly extract a
> resource directly from a ComponentManager. That would suck
> unbelievably,
> would never scale and lead to all sorts of design
> compromises. You aquire a
> SocketManager who does the work.
Here is the first case of pattern/antipattern. If black magick
is not your taste (very few people like it), then we need to
come up with a sound solution.
We have been harping on the Secure/Unsecure connection as our
poster child for multiple types of components for the same
function.
We already have a ConnectionManager defined. The problem is
that is is centered around the *Connection*. Why is this a
problem?
If it is common for a system to choose whether or not a connection
is encrypted or not, the responsibility should not be on the
container to do black magick and come up with the proper connection
manager. There is too much that can go wrong in this case. The
consequences of broadcasting sensitive information over a clear
line are too great to fully trust the meta-data model on this
case--esp. for military projects where the cost for error might
be measured in the life or death of the troops.
The better solution would be to change the abstraction so that
we can ask the ConnectionManager to return a secure/encrypted
connection. In other words, the COnnectionManager should be
able to handle the finite possibilities of secure or unsecure
(I almost typed insecure, but that is a problem of self
confidence ;P ).
Changing the abstraction helps in those cases where the choices
are finite, and few. In this case we have a choice between a
secure connection and an insecure connection.
There is no constraint modeling that has to be done. There is
no ambiguity as to which component should be grabbed. There is
also little chance that a disgruntled assembler could hose your
project so easily.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Donald <pe...@apache.org>.
On Wed, 26 Jun 2002 16:26, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > It really comes down to what the component writer wants to classify as a
> > constraint and what they want to classify as a hint/policy. The component
> > writer could choose to make "secure" a constraint or they could choose to
> > make it a hint.
>
> Peter, what you say makes sense, but how the f**k can you make the client
> specify a hint||constraint with
>
> SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
>
> ?!?!?!?!?!?
ummm ... metadata?
BTW there is not a chance that I would suggest that you directly extract a
resource directly from a ComponentManager. That would suck unbelievably,
would never scale and lead to all sorts of design compromises. You aquire a
SocketManager who does the work.
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
>
> It really comes down to what the component writer wants to classify as a
> constraint and what they want to classify as a hint/policy. The component
> writer could choose to make "secure" a constraint or they could choose to
> make it a hint.
Peter, what you say makes sense, but how the f**k can you make the client
specify a hint||constraint with
SSLSocket sslSocket = (SSLSocket)cm.lookup(socketType);
?!?!?!?!?!?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Donald <pe...@apache.org>.
On Wed, 26 Jun 2002 10:55, Robert Mouat wrote:
> yes, I think that I got a little carried away (or confused :) -- I was
> thinking more along the lines of policies (and that the container would
> try to enforce them)...
Naah - I agree that would suck ;)
> something like: "a component knew that it had sensitive information to
> send and that it *must* have a secure connection".
>
> I think I said somewhere (or at least meant to) that interfaces were
> probably the only constraints that had to be enforced (interfaces implying
> contracts) -- but it seems conceivable that there are others.
It really comes down to what the component writer wants to classify as a
constraint and what they want to classify as a hint/policy. The component
writer could choose to make "secure" a constraint or they could choose to
make it a hint.
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Peter Donald wrote:
> On Wed, 26 Jun 2002 07:59, Robert Mouat wrote:
> > let me reword it a little: if the client specifies (via metadata) that
> > the connection it is requesting *must* be SSL, and the container is going
> > to enforce the constraint - then the assembler can circumvent it by
> > creating another component that tells the container it provides an SSL
> > connection (and instead passes all method calls onto a tunnelling
> > component).
>
> attributes on a dependency can either be constraints or hints (aka policys).
> The container enforces constraints as if does not the component will not
> work. If the attributes are hints then they try to enforce them but assembler
> can overide it at any time they feel like.
>
> ie if Client specifies they MUST use SSL enabled ConnManager then it is likely
> because they do something like
>
> final SSLSocket sslSocket = (SSLSocket)myConnMann.getSocket(...);
> sslSocket.setClientCerts( myCertificates );
>
> If the constraint is not enforced then the application will fail when
> executing - precisely what we want to avoid by tagging dependency with
> constraints.
>
> ie Don't confuse constraints and hints/policys. hints/policys just suggest
> good characteristerics of the provider but need not be enforced.
yes, I think that I got a little carried away (or confused :) -- I was
thinking more along the lines of policies (and that the container would
try to enforce them)...
something like: "a component knew that it had sensitive information to
send and that it *must* have a secure connection".
I think I said somewhere (or at least meant to) that interfaces were
probably the only constraints that had to be enforced (interfaces implying
contracts) -- but it seems conceivable that there are others.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Wed, 26 Jun 2002 07:59, Robert Mouat wrote:
> let me reword it a little: if the client specifies (via metadata) that
> the connection it is requesting *must* be SSL, and the container is going
> to enforce the constraint - then the assembler can circumvent it by
> creating another component that tells the container it provides an SSL
> connection (and instead passes all method calls onto a tunnelling
> component).
attributes on a dependency can either be constraints or hints (aka policys).
The container enforces constraints as if does not the component will not
work. If the attributes are hints then they try to enforce them but assembler
can overide it at any time they feel like.
ie if Client specifies they MUST use SSL enabled ConnManager then it is likely
because they do something like
final SSLSocket sslSocket = (SSLSocket)myConnMann.getSocket(...);
sslSocket.setClientCerts( myCertificates );
If the constraint is not enforced then the application will fail when
executing - precisely what we want to avoid by tagging dependency with
constraints.
ie Don't confuse constraints and hints/policys. hints/policys just suggest
good characteristerics of the provider but need not be enforced.
--
Cheers,
Peter Donald
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stephen McConnell <mc...@osm.net>.
Robert Mouat wrote:
>Stephen McConnell wrote:
>
><snip/>
>
>>><rant subject="Assembler as God">
>>>
>>>[by assembler I'm referring to the person who puts the final application
>>>together - including things like writing the code for a programatically
>>>assembled container (like fortress), and writing a cocoon sitemap].
>>>
>>>The framework describes a contract between a component and a container -
>>>this is good for both component writers and container writers... but
>>>components and containers are both subject to the whims of the assembler.
>>>
>>>
>>Yep.
>>
>>
>>>The assembler gets the last say. The assembler puts everything together
>>>to form the final application - choosing components and the container to
>>>suit their needs. [though perhaps not always with a choice of container]
>>>
>>>If a component/container isn't flexible enough then the assembler can
>>>choose another (or potentially write one).
>>>
>>>
>>That's the idea I have in mind - different containers doing different
>>things but a particular cointainer does its particular thing right.
>> Eliminate the issue of onoe container for all - instead - leverage the
>>right tool for the job.
>>
>>
>>>I think that this should be recognised in how a component is looked up -
>>>i.e. when a client asks for a particular role, the assembler should be
>>>able to specify exactly what component it gets.
>>>
>>Where an assembler is assemberling the content of an application and the
>>ingridients are classes and profiles - then yes. I agree. When the
>>ingridients are services from somewhere else - then the assembler has to
>>live with the service requested based on the quality of the container in
>>support of a particular idea of service defintion and fitne4ss-for-purpose.
>>
>
>I disagree that the assembler *has* to live with anything -- and think
>they should be able to override any fitness-for-purpose decisions... see
>below...
>
>
>>>In that respect components only get to demand what they need in terms of
>>>interfaces -- anything else they have to humbly request from the
>>>assembler, and not complain when denied.
>>>
>>>
>>>
>>Yep.
>>
>>
>>>e.g.
>>>
>>>If a component asks for a tcp connection, then suggests that it should be
>>>SSL - I, as assembler should be able to say "denied: your connection will
>>>be tunnelled via ssh instead" -- of course if the component had requested
>>>a 'secure' connection, the request would have been approved (or not if it
>>>is in a development/testing environment).
>>>
>>Not ready to agree on that just yet. Personally I hate the notion of
>>"suggestions"and "hints" - these notions don't exist in the framework
>>and it has not been formalized anywere else - and until that happens ...
>>don't expect way cool solutions.
>>
>
>hmmm, 'suggests' was a bad choice of words, I wasn't necessarily thinking
>about 'hints', but rather metadata constraints.
>
>
>
>>>Now suppose that the component and the container are conspiring against
>>>me, the assembler - and the component tells the container (via metadata)
>>>that it insists that the connection be SSL, and the container decides to
>>>enforce that... well I could write a small wrapper component that lied to
>>>the container saying that it provided an SSL connection, but instead
>>>simply used another component that provided an unencrypted tcp connection
>>>that happened to go through a VPN tunnel.
>>>
>>>I am the assembler, I always win :)
>>>
>>>
>>>
>>I'm not really following the above too well.
>>The guy doing the assembnly is simply working with the
>>constraints/limitations of the language used by a particular container.
>> You wind to the extent that you (a) choose the appropriate container as
>>a deployment vehicle, and (b) leverage the container to the best of its
>>ability.
>>
>
>let me reword it a little: if the client specifies (via metadata) that
>the connection it is requesting *must* be SSL, and the container is going
>to enforce the constraint
>
Lets just say that a client, using some application, wishes to aquire a
component from the application (either statically through a dependecy
declaration in meta data or dynamically through an application interface).
>- then the assembler can circumvent it by
>creating another component that tells the container it provides an SSL
>connection (and instead passes all method calls onto a tunnelling
>component).
>
The continer (the implementation that is handling the request) could do
anything it likes and provide whatever black-magic it likes such that an
assembler could theoretically cause whatever wiring they want. I don't
know of such a container - but what is more likely is a container that
will let an assembler express assembly needs within a context that it
can validate - i.e. make sure that anything done by an assembler is
structurally valid. I don't imagine a container that would allow
overriding a metadata as that is really structurally foundation stuff -
and with few exceptions - consititues the computational contract - and
bypassing that will be enabling a invalid state. I think what your
getting at is the need/interest/necessity of a container implementation
to provide a sufficient degree of customization through its
configuration such that the assembler maintains control. This is an
emerging topic - as we move forward with common approaches to structural
component management - you will see a shift in focus to the differences
between contains in the style used to expression profiles, the potential
depth of profiles, and the different approaches to assembly.
>
>
>What is the point in a container telling an assembler that they *can't*
>give a particular component to a client?
>
The point is that if a container cannot provide a solution within the
scope of features/benefits/QoS profile - then it cannot do it. That is
fair and reasonable.
>The assembler can easily
>circumvent this -- the only constraint that cannot be bypassed is the
>interfaces the client requires of the component (since these will cause
>runtime errors when the client does a cast).
>
An assemble, using a container as the tool - could easily circumvent
this - should the container in question provide this type of
support/feature/beneefit. But is a container impelmentation issue.
>
>[a warning might be appropiate, as long as the assembler can supress it]
>
>
>>>Anyway, the point is that the framework should recognise the role that the
>>>assembler plays and not try to limit the assemblers ability to chose what
>>>components client get for particular roles -- the assembler is the only
>>>one who can see the 'big picture'.
>>>
>>A container brings God down to earth because the container knows about
>>reality.
>>God's just speculating :-)
>>
>
>If the assembler knows enough about the components they are using, they
>don't need a reality check -- if they don't know enough (poor
>documentation, or failing to read the documentation) then a recalcitrant
>container isn't going to prevent problems :)
>
Conclusion - I think we are a similar track as far as "delivering power
to the assembler". I'm not ready to totally jump to the level of
flexibility your suggesting because I see this a breaking contractual
obligations. One more point is that I'm also assuming the following model:
-------------------------------
| can aquire |
| services from |
1 | a parent |
V |
|====================================| services
| container |-------------> components
|------------------------------------|
| (manages an internal set of |
| services based on its own |
| assembly and management model} |
|====================================|
| ^
| provides services to | 0..n
| child container |
-------------------------------
The key thing here is that I want to be able to use Fortress as a
container that potentially uses services that Merlin manages, that is
potentially using services the Phoenix is managing, etc., etc. Bottom
line, if you line up Phoenix, Merlin, Fortress - they are different -
they serve different interests - federating these benefits seems to me
to me a better solution.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Robert Mouat wrote:
><bigMeaningfulSnip/>
>
>If the assembler knows enough about the components they are using, they
>don't need a reality check -- if they don't know enough (poor
>documentation, or failing to read the documentation) then a recalcitrant
>container isn't going to prevent problems :)
>
>
....another blow for the concept of perfection - a la the asses thing in
previous posts. You covered every base, only to conclude that you are
hosed anyway.
<conclusion>
If you can't make it perfect, just make it simple and dumb, and
keep deleting everything that can't be agreed upon. You can then focus
on the practices manual and examples to keep people safe, rather than
the perfection of the code.
<conclusion/>
<cuteSaying>
If dangerous COP was coded around, only committers would be able to
figure it out anyway. [sung to the tune of - if guns were outlawed...]
<cuteSaying/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Stephen McConnell wrote:
> Robert Mouat wrote:
<snip/>
> >dont't get me wrong here -- I'm not against 'type checking/safety' --
> >perhaps what is needed is a 'cast' so that the assembler can do what they
> >want as long as they acknowledge that it isn't the intended use.
> >
> >That way they can explicitly accept responsibility for when they go
> >against the metadata constraints.
>
> But the metadata constraint isn't the issue. That simply the
> declaration by a component of a contract it is expecting to be
> fulfilled. The next question is "how is that contract going to be
> fulfilled". At this point your getting into the features and benefits
> of different containers and to varying extends - the contribution from
> an "assembler" person. Some containers will be strict and inflexible,
> others will try to reduce the time and effort needed by an "assembler" -
> and facilitate a commensurate reduction in deployment errors. The
> questions your raising are 100% container specific - you choose a
> container and it provides you with certain features and benefits. Those
> features and benefits will meet different requirements - I guess the key
> thing for me is that I don't want to see one-container for Avalon - I
> want to see different containers solving different problems - each
> consistent - and each one capable of being a provider or consumer of
> another.
yes, these messages have been rather implementation dependant -- but then,
I started by wanting a component to be able to make assumptions about the
abilities of the assembler (which is close to being an implementation
thing)...
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stephen McConnell <mc...@osm.net>.
Robert Mouat wrote:
>Robert Mouat wrote:
>
>
>>Stephen McConnell wrote:
>>
>>
>
><snip/>
>
>
>
>>>>Anyway, the point is that the framework should recognise the role that the
>>>>assembler plays and not try to limit the assemblers ability to chose what
>>>>components client get for particular roles -- the assembler is the only
>>>>one who can see the 'big picture'.
>>>>
>>>>
>>>A container brings God down to earth because the container knows about
>>>reality.
>>>God's just speculating :-)
>>>
>>>
>>If the assembler knows enough about the components they are using, they
>>don't need a reality check -- if they don't know enough (poor
>>documentation, or failing to read the documentation) then a recalcitrant
>>container isn't going to prevent problems :)
>>
>>
>
>dont't get me wrong here -- I'm not against 'type checking/safety' --
>perhaps what is needed is a 'cast' so that the assembler can do what they
>want as long as they acknowledge that it isn't the intended use.
>
>That way they can explicitly accept responsibility for when they go
>against the metadata constraints.
>
But the metadata constraint isn't the issue. That simply the
declaration by a component of a contract it is expecting to be
fulfilled. The next question is "how is that contract going to be
fulfilled". At this point your getting into the features and benefits
of different containers and to varying extends - the contribution from
an "assembler" person. Some containers will be strict and inflexible,
others will try to reduce the time and effort needed by an "assembler" -
and facilitate a commensurate reduction in deployment errors. The
questions your raising are 100% container specific - you choose a
container and it provides you with certain features and benefits. Those
features and benefits will meet different requirements - I guess the key
thing for me is that I don't want to see one-container for Avalon - I
want to see different containers solving different problems - each
consistent - and each one capable of being a provider or consumer of
another.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Robert Mouat wrote:
> Stephen McConnell wrote:
<snip/>
> > >Anyway, the point is that the framework should recognise the role that the
> > >assembler plays and not try to limit the assemblers ability to chose what
> > >components client get for particular roles -- the assembler is the only
> > >one who can see the 'big picture'.
> >
> > A container brings God down to earth because the container knows about
> > reality.
> > God's just speculating :-)
>
> If the assembler knows enough about the components they are using, they
> don't need a reality check -- if they don't know enough (poor
> documentation, or failing to read the documentation) then a recalcitrant
> container isn't going to prevent problems :)
dont't get me wrong here -- I'm not against 'type checking/safety' --
perhaps what is needed is a 'cast' so that the assembler can do what they
want as long as they acknowledge that it isn't the intended use.
That way they can explicitly accept responsibility for when they go
against the metadata constraints.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Stephen McConnell wrote:
<snip/>
> ><rant subject="Assembler as God">
> >
> >[by assembler I'm referring to the person who puts the final application
> >together - including things like writing the code for a programatically
> >assembled container (like fortress), and writing a cocoon sitemap].
> >
> >The framework describes a contract between a component and a container -
> >this is good for both component writers and container writers... but
> >components and containers are both subject to the whims of the assembler.
> >
>
> Yep.
>
> >
> >The assembler gets the last say. The assembler puts everything together
> >to form the final application - choosing components and the container to
> >suit their needs. [though perhaps not always with a choice of container]
> >
> >If a component/container isn't flexible enough then the assembler can
> >choose another (or potentially write one).
> >
>
> That's the idea I have in mind - different containers doing different
> things but a particular cointainer does its particular thing right.
> Eliminate the issue of onoe container for all - instead - leverage the
> right tool for the job.
>
> >I think that this should be recognised in how a component is looked up -
> >i.e. when a client asks for a particular role, the assembler should be
> >able to specify exactly what component it gets.
>
> Where an assembler is assemberling the content of an application and the
> ingridients are classes and profiles - then yes. I agree. When the
> ingridients are services from somewhere else - then the assembler has to
> live with the service requested based on the quality of the container in
> support of a particular idea of service defintion and fitne4ss-for-purpose.
I disagree that the assembler *has* to live with anything -- and think
they should be able to override any fitness-for-purpose decisions... see
below...
> >In that respect components only get to demand what they need in terms of
> >interfaces -- anything else they have to humbly request from the
> >assembler, and not complain when denied.
> >
> >
>
> Yep.
>
> >
> >e.g.
> >
> >If a component asks for a tcp connection, then suggests that it should be
> >SSL - I, as assembler should be able to say "denied: your connection will
> >be tunnelled via ssh instead" -- of course if the component had requested
> >a 'secure' connection, the request would have been approved (or not if it
> >is in a development/testing environment).
>
> Not ready to agree on that just yet. Personally I hate the notion of
> "suggestions"and "hints" - these notions don't exist in the framework
> and it has not been formalized anywere else - and until that happens ...
> don't expect way cool solutions.
hmmm, 'suggests' was a bad choice of words, I wasn't necessarily thinking
about 'hints', but rather metadata constraints.
> >Now suppose that the component and the container are conspiring against
> >me, the assembler - and the component tells the container (via metadata)
> >that it insists that the connection be SSL, and the container decides to
> >enforce that... well I could write a small wrapper component that lied to
> >the container saying that it provided an SSL connection, but instead
> >simply used another component that provided an unencrypted tcp connection
> >that happened to go through a VPN tunnel.
> >
> >I am the assembler, I always win :)
> >
> >
>
> I'm not really following the above too well.
> The guy doing the assembnly is simply working with the
> constraints/limitations of the language used by a particular container.
> You wind to the extent that you (a) choose the appropriate container as
> a deployment vehicle, and (b) leverage the container to the best of its
> ability.
let me reword it a little: if the client specifies (via metadata) that
the connection it is requesting *must* be SSL, and the container is going
to enforce the constraint - then the assembler can circumvent it by
creating another component that tells the container it provides an SSL
connection (and instead passes all method calls onto a tunnelling
component).
What is the point in a container telling an assembler that they *can't*
give a particular component to a client? The assembler can easily
circumvent this -- the only constraint that cannot be bypassed is the
interfaces the client requires of the component (since these will cause
runtime errors when the client does a cast).
[a warning might be appropiate, as long as the assembler can supress it]
> >
> >Anyway, the point is that the framework should recognise the role that the
> >assembler plays and not try to limit the assemblers ability to chose what
> >components client get for particular roles -- the assembler is the only
> >one who can see the 'big picture'.
>
> A container brings God down to earth because the container knows about
> reality.
> God's just speculating :-)
If the assembler knows enough about the components they are using, they
don't need a reality check -- if they don't know enough (poor
documentation, or failing to read the documentation) then a recalcitrant
container isn't going to prevent problems :)
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stephen McConnell <mc...@osm.net>.
Robert Mouat wrote:
>Steve,
>
>yes, what I described is more of an application composed of a hierarchy of
>functional units (and that hierarchy, while defined by configuration,
>remained static for the applications life)... however I think that avalon
>should support this sort of hierarchy because of what happened next with
>some of the components that were used in it...
>
Just so I get my own terminology a little better qualifier - this is
what I am
refering to when I use the term application and container:
application
an interface that exposes services that
may be provided to a client and/or child
applications
container
an implementation of an application that manages that
establishment of services possibly in collaboration
with a parent application
>
>In the example I described below the controller and units were not at the
>top or bottom of the hierarchy (the units produced data, so had a
>dependence on a DataCollector which had to be unique for each unit)... The
>application had a lot of other pieces, some related to the functionality
>of the user interface...
>
No problem - this is classic component dependecy stuff if I understand
correctly.
>
>The framework (developed in-house) was suitable for such an application
>(hierarchy of functional units and scoped names)... Later they thought -
>"wouldn't it be good if we could use some of our components in a webapp
>since we want the web user-interface to share some functionality with the
>application user-interface" (though obviously not the same look-and-feel).
>
>Unfortunately the design of the framework prevented this (it used static
>methods to fetch global configuration that would not be global in a
>webapp)... [disclaimer: I wasn't around when the framework was designed
>:)]
>
>The point is that what is a 'function unit' within an application could
>also become a component in a different setting
>
Absolutely.
>(though as I said not with
>the framework that was used).
>
>
>Basically there are 2 reasons to allow avalon to support using components
>as 'functional units' and having name scoping:
>
>1. so that when writing such an application you can re-use existing
>components as your functional units.
>
Yep.
>
>2. having written such an application, your functional units can be used
>as components elsewhere.
>
Yep
>I'd like to finish with a rant:
>
><rant subject="Assembler as God">
>
>[by assembler I'm referring to the person who puts the final application
>together - including things like writing the code for a programatically
>assembled container (like fortress), and writing a cocoon sitemap].
>
>The framework describes a contract between a component and a container -
>this is good for both component writers and container writers... but
>components and containers are both subject to the whims of the assembler.
>
Yep.
>
>The assembler gets the last say. The assembler puts everything together
>to form the final application - choosing components and the container to
>suit their needs. [though perhaps not always with a choice of container]
>
>If a component/container isn't flexible enough then the assembler can
>choose another (or potentially write one).
>
That's the idea I have in mind - different containers doing different
things but a particular cointainer does its particular thing right.
Eliminate the issue of onoe container for all - instead - leverage the
right tool for the job.
>
>I think that this should be recognised in how a component is looked up -
>i.e. when a client asks for a particular role, the assembler should be
>able to specify exactly what component it gets.
>
>
Where an assembler is assemberling the content of an application and the
ingridients are classes and profiles - then yes. I agree. When the
ingridients are services from somewhere else - then the assembler has to
live with the service requested based on the quality of the container in
support of a particular idea of service defintion and fitne4ss-for-purpose.
>In that respect components only get to demand what they need in terms of
>interfaces -- anything else they have to humbly request from the
>assembler, and not complain when denied.
>
>
Yep.
>
>e.g.
>
>If a component asks for a tcp connection, then suggests that it should be
>SSL - I, as assembler should be able to say "denied: your connection will
>be tunnelled via ssh instead" -- of course if the component had requested
>a 'secure' connection, the request would have been approved (or not if it
>is in a development/testing environment).
>
Not ready to agree on that just yet. Personally I hate the notion of
"suggestions"and "hints" - these notions don't exist in the framework
and it has not been formalized anywere else - and until that happens ...
don't expect way cool solutions.
>
>Now suppose that the component and the container are conspiring against
>me, the assembler - and the component tells the container (via metadata)
>that it insists that the connection be SSL, and the container decides to
>enforce that... well I could write a small wrapper component that lied to
>the container saying that it provided an SSL connection, but instead
>simply used another component that provided an unencrypted tcp connection
>that happened to go through a VPN tunnel.
>
>I am the assembler, I always win :)
>
>
I'm not really following the above too well.
The guy doing the assembnly is simply working with the
constraints/limitations of the language used by a particular container.
You wind to the extent that you (a) choose the appropriate container as
a deployment vehicle, and (b) leverage the container to the best of its
ability.
>
>Anyway, the point is that the framework should recognise the role that the
>assembler plays and not try to limit the assemblers ability to chose what
>components client get for particular roles -- the assembler is the only
>one who can see the 'big picture'.
>
A container brings God down to earth because the container knows about
reality.
God's just speculating :-)
>
>If a component really, really, wants an SSL connection then it can always
>embed one inside itself.
>
>[of course metadata can be useful, if the assembler is lazy and the
>container has to guess what component to give the client]
>
>
On the subject of laziness - assemblers should be given the right to be
lazy.
Developers on the otherhand cannot - we can give the developer tools -
and we give the developer a hard time when things are not done correctly
- and we deliver a buch of solutions that make life an enjoyable process.
Cheers, Steve.
<standard-disclaimer>
Nothing stated above has anything to with anything - just random noise. :-)
<standard-disclaimer>
></rant>
>
>Robert.
>
>
>
>Stephen McConnell wrote:
>
>
>
>>Robert:
>>
>>Thinking-out-load ...
>>
>>Relative to my current thinking and work I'm currently doing related to
>>containerkit, what you are describing below is an application. It's an
>>application because you are describing the "content" of a functional
>>unit. In the example, your using a single class as the base (but this
>>is semi-academic). In effect you are describing a series of type
>>profiles based on a single class. Each profile represents the
>>association of a base type with criteria concerning the deployment of
>>the type. These profiles are named such that each name is unique within
>>the application context (which is different to role names in a component
>>type context).
>>
>>Your client component needs to declare a dependecy on the controller
>>application and once that has been resolved via lookup, it then get the
>>service you want using the profile name as the key in the application
>>scope of the controller (or any other application specific method you
>>choose). That operation is specific to the application at this time.
>> However, there is thinking going on about how application/container
>>hierachies could be managed - which would potentially enable your lookup
>>operation to be directed to the application in which the name is scoped
>>- but that's pure speculation at the moment so don't ask too many
>>questions just yet! Like I said ... thinking-out-load.
>>
>>Hope this helps.
>>
>>Cheers, Steve.
>>
>>
>>Robert Mouat wrote:
>>
>>
>>
>>>I have a use case (from previous work I did in a non-avalon framework)
>>>that I'm not sure how to reconcile with the current metadata/lookup()
>>>proposal...
>>>
>>>basically there are two issues:
>>>1. multiple components coming from the same class (with different configuration).
>>>2. passing role names into a component via configuration.
>>>
>>>The situation is that I have a controller, that controls multiple units
>>>(so that they can work together) -- the number of units it controls (and
>>>how they work) is specified in the controller's configuration. The units
>>>are generally all going to be of the same class but with different
>>>configuration (e.g. different ports).
>>>
>>>so I will have something like:
>>>
>>><component id="unit1" class="UnitImpl">
>>> <!-- unit1 configuration -->
>>></component>
>>>
>>><component id="unit2" class"UnitImpl">
>>> <!-- unit2 configuration -->
>>></component>
>>>
>>><!-- ... -->
>>>
>>><component id="controller" class="UnitController">
>>> <!--
>>> ...
>>> <unit name="unit1"/>
>>> <unit name="unit2"/>
>>> ...
>>> -->
>>></component>
>>>
>>>(This is perhaps not too dissimilar in concept to a cocoon sitemap).
>>>
>>>In an ideal situation I'd like the controller to be able to do something
>>>like:
>>>
>>> unit[i] = (Unit) lookup( unitNames[i] );
>>>
>>>where unitNames[] comes from the configuration and is something like
>>> { "unit1", "unit2" /* ... */ }
>>>
>>>It is impossible for the controller to declare these dependencies in
>>>metadata - since they aren't known until assemble time.
>>>
>>>Now I don't fully understand how the current metadata proposal governs
>>>component resolution, but I get the impression that I can't write the
>>>above in a container independent way (and hence not in a reusable way)...
>>>I could probably use a Selector (e.g. lookup("unit-selector")), but then
>>>the Selector would have to be container specific for the same reasons.
>>>
>>>The reason I'm not sure that this will work is that when I look over the
>>>emails regarding metadata/lookup() it seems that the job of the assembler,
>>>as far as determining a mapping from role names to components, is absent
>>>-- maybe it was just assumed (and not explicitly mentioned).
>>>
>>>What I'm looking for is some assurance the the job of the assembler isn't
>>>going to be replaced by metadata.
>>>
>>>Am I misunderstanding something about the metadata/lookup() proposal? is
>>>it possible to write such a beast in a container independent way?
>>>
>>>- or -
>>>
>>>is 'controller' really a block (or the controller+units a single big
>>>component)? And it should embed Fortress (or another container), and take
>>>in all the configuration for the units as well as it's own configuration?
>>>
>>>Robert.
>>>
>>>On Mon, 24 Jun 2002, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Date: Mon, 24 Jun 2002 15:30:49 -0400
>>>>From: Berin Loritsch <bl...@apache.org>
>>>>Reply-To: Avalon Developers List <av...@jakarta.apache.org>,
>>>> bloritsch@apache.org
>>>>To: 'Avalon Developers List' <av...@jakarta.apache.org>
>>>>Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
>>>> 'hints')
>>>>
>>>>While Stefano has some important points, we do have to bring practice
>>>>into view. An abstraction without foundation in reality is doomed to
>>>>failure. So let's look at this pragmatically.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>>>>
>>>>>Ok, this said, let's move on. I see two different ways of
>>>>>looking for a
>>>>>component:
>>>>>
>>>>>1) I need something that does this.
>>>>>
>>>>>2) I need something that does this, and should work in this context
>>>>>
>>>>>Two real life examples:
>>>>>
>>>>>1)
>>>>>composer: I need a component that implements 'screwdriver'
>>>>>componentManager: here it is
>>>>>
>>>>>2)
>>>>>composer: I need a component that implements 'screwdriver'
>>>>>and I'll use it on screws of 3 mm of diameter.
>>>>>componentManager: here it is
>>>>>
>>>>>It has been suggested that the working context is just
>>>>>another information you pass in the role, so, in our
>>>>>examples, we would have an inflation of roles for each
>>>>>screwdriver and each possible screw size or size ranges.
>>>>>
>>>>>Please, tell me, am I the only one who doesn't get a good
>>>>>feeling out of this?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>In the hardware realm for ordinary household projects, you
>>>>only have to worry about three basic sizes of screwdrivers
>>>>and two different types. There are Philips head and Flat
>>>>head screwdrivers. They come in three sizes (#1, #2, #3).
>>>>For 90% of woodworking projects you use a Philips #2. For 90%
>>>>of electrical projects you use a Flathead #2 (or #1).
>>>>
>>>>The bottom line is that while there are many different
>>>>possibilities of roles, only a couple are really necessary in
>>>>a system.
>>>>
>>>>For projects like Cocoon where the Sitemap is not only the
>>>>container for its components, but it also chooses the
>>>>component necessary for the job, it is really better for the
>>>>Sitemap container to choose the component in a Cocoon specific
>>>>way.
>>>>
>>>>What you are accusing Peter and company of doing is not really
>>>>any different than what Cocoon does. The lookup might change
>>>>
>>>>
>>>>from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
>>>
>>>
>>>>but the general outcome is the same. There is *essentially*
>>>>ten different roles if we are being true to what it conceptually
>>>>is.
>>>>
>>>>To the pipeline, A generator is a generator is a generator.
>>>>To the sitemap, we may have ten different implementations that
>>>>we choose from. The *sitemap* chooses which of those 10
>>>>generators are used depending on context. Because it is a
>>>>container in and of itself, it can do so in any way it chooses.
>>>>Effectively each individual Generator performs a different role.
>>>>One pulls info from the filesystem, another pulls it from an
>>>>external site, and yet another will pull it from a database.
>>>>The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
>>>>directly request the generator. The sitemap sets the generator.
>>>>
>>>>So for real practicality's sake, we either have a distinct
>>>>role for each of the Generators or we have a smart container.
>>>>
>>>>Think of it in terms of the Chorus in a theatrical play. They
>>>>act as one, but they have their own part to play in the harmony
>>>>or narration of the play. There might be three distinct people
>>>>on the stage at one time that perform the same general function.
>>>>It is the same with the concept of generators in Cocoon.
>>>>
>>>>Please tell me if I have confused you more than I have clarified
>>>>things.
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stephen McConnell <mc...@osm.net>.
Robert Mouat wrote:
>Robert Mouat wrote:
>
>
>
>>Leo Sutic wrote:
>>
>>
>>
>>>Robert,
>>>
>>>we all agree.
>>>
>>>
>>ok, I got a bit paranoid that metadata was going to replace the job of the
>>assembler.
>>
>>
>
>re-reading some of the recent emails - I think I get it now - the
>difference is between blocks and components:
>
> - a block is a component with metadata.
>
>
My take ...
A component is an object that implements a licecycle policy. A
component may expose the lifecycle contract through metadata and other
means. Certain containers will enforce a formal comonent contact.
Phoenix is a container that uses a meta-model described through a
constuct called a block. This formal structure can be considered to be
the original formal-component defintion.
> - when lookup(roleName) is called:
>
> - if the client comes with no metadata specifying the meaning of the
> roleName, then the component/block returned is the one specified by
> the assembler.
>
When a client invokes lookup, the result returned (today) is completely
an implementation issue for a container. Assurance concerning the
semantics of lookup on a component manager are insufficiently defined
today. You go to the documentation of the container you are using, and
look for information about the semantics and assumptions that the
contaer applies to the lookup opertion. In the future, I hope that this
will be eliminated and that we will be able to provide a formal contract
from client, through lookup, to container - and in that specification,
define how varients of the formal process can be handled in a consistent
way.
>
> - if the client has metadata that specifies the meaning of the
> roleName then the container compares this with the metadata for the
> blocks and returns one that matches. [aside: I assume that the
> assembler can overide this]
>
Metadata instructions do not define the routing of a supplier componet
to a dependent component. This is the resonsibility of the assembler.
Certtain contains can fill in missing information and make the process
easier for the assembler. For example, in the absence of an explicit
assembly directive, Merlin will attempt to automatically complete the
routing of the entirte dependency chain.
>
>is this correct?
>
Yyyyyyyy ... es.
>
>sorry for taking up so much bandwidth trying to figure this out.
>
Ce cool!
Cheers, Steve.
>
>Robert.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 25 June 2002 05:04 pm, Leo Simons wrote:
> > re-reading some of the recent emails - I think I get it now - the
> > difference is between blocks and components:
> >
> > - a block is a component with metadata.
> >
> > - when lookup(roleName) is called:
> >
> > - if the client comes with no metadata specifying the meaning of the
> > roleName, then the component/block returned is the one specified by
> > the assembler.
> >
> > - if the client has metadata that specifies the meaning of the
> > roleName then the container compares this with the metadata for the
> > blocks and returns one that matches. [aside: I assume that the
> > assembler can overide this]
> >
> > is this correct?
>
> that's what the Leos seem to agree on...haven't heard from the peter's
> yet though =)
Pretty much. The information specified by the assembler could also be
construed as metadata :)
> recent discussion is still loads of theory. Once code is in place and
> working, we'll be voting, I guess...
Yes. *always* easier to deal with working code.
> - Leo, lost half a nail on a CPU cooler today
damn. must have hurt.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for
'hints')
Posted by Leo Simons <le...@apache.org>.
> re-reading some of the recent emails - I think I get it now - the
> difference is between blocks and components:
>
> - a block is a component with metadata.
>
> - when lookup(roleName) is called:
>
> - if the client comes with no metadata specifying the meaning of the
> roleName, then the component/block returned is the one specified by
> the assembler.
>
> - if the client has metadata that specifies the meaning of the
> roleName then the container compares this with the metadata for the
> blocks and returns one that matches. [aside: I assume that the
> assembler can overide this]
>
> is this correct?
that's what the Leos seem to agree on...haven't heard from the peter's
yet though =)
recent discussion is still loads of theory. Once code is in place and
working, we'll be voting, I guess...
of course, regardless of any cool roles 'n contracts we dream up, an
assembler that has access to ant and source code can override just about
anything.
grz,
- Leo, lost half a nail on a CPU cooler today
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Robert Mouat wrote:
> Leo Sutic wrote:
>
> > Robert,
> >
> > we all agree.
>
> ok, I got a bit paranoid that metadata was going to replace the job of the
> assembler.
re-reading some of the recent emails - I think I get it now - the
difference is between blocks and components:
- a block is a component with metadata.
- when lookup(roleName) is called:
- if the client comes with no metadata specifying the meaning of the
roleName, then the component/block returned is the one specified by
the assembler.
- if the client has metadata that specifies the meaning of the
roleName then the container compares this with the metadata for the
blocks and returns one that matches. [aside: I assume that the
assembler can overide this]
is this correct?
sorry for taking up so much bandwidth trying to figure this out.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Leo Sutic wrote:
> Robert,
>
> we all agree.
ok, I got a bit paranoid that metadata was going to replace the job of the
assembler.
> Is this something like what you seek:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=102476881915187&w=2
yes, pretty much.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Robert,
we all agree.
Is this something like what you seek:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102476881915187&w=2
/LS
> -----Original Message-----
> From: Robert Mouat [mailto:robert@mouat.net]
> Sent: den 25 juni 2002 21:39
> To: Avalon Developers List
> Subject: Re: Fresh Outlook: (was RE: [desperate plea] RE: The
> need for 'hints')
>
>
> Robert Mouat wrote:
>
> > <rant subject="Assembler as God">
> <snip/>
> > </rant>
>
> trying to pull something constructive from my previous rant...
>
> Things I'd like:
>
> 1. the ability for the same implementation class to be used
> as more than one component (e.g. with different configuration).
>
> 2. the piece of mind to be able to write a component and not
> worry about name space clashes when looking up roles --
> allowing me use generic role names -- or in the case of (1)
> above - where it is likely that different components from the
> same class will request the same role, but should be given
> different components.
>
> 3. The ability to request role names passed in with the
> configuration - trusting that the assembler has control of
> both the configuration and the lookup (so can match the role
> name with the appropiate component).
>
>
> Item 3 could be done using hints (but probably not 2).
>
> However 1, 2 and 3 could be achieved if the assembler is
> given the ability to define a mapping of role names to
> components for each client. So I'd like to suggest that this
> ability be part of the framework - i.e. state that containers
> should give assemblers this ability (so that component
> writers can feel confident that when writing code that
> assumes 2 and 3 they are not sacrificing reusuability).
>
> Something like:
>
> "Component writers may assume that a container will give
> the assembler the ability to specify (uniquely for each
> client) which component will be returned whenever a role is
> looked up. Further a component may receive role names via
> the configuration."
>
>
> Finally I'd also like:
>
> 4. metadata be optional. (relying on the assembler if it is
> missing).
>
> (but that's mainly because I'm lazy).
>
>
> Robert.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Robert Mouat wrote:
> <rant subject="Assembler as God">
<snip/>
> </rant>
trying to pull something constructive from my previous rant...
Things I'd like:
1. the ability for the same implementation class to be used as more than
one component (e.g. with different configuration).
2. the piece of mind to be able to write a component and not worry about
name space clashes when looking up roles -- allowing me use generic role
names -- or in the case of (1) above - where it is likely that different
components from the same class will request the same role, but should be
given different components.
3. The ability to request role names passed in with the configuration -
trusting that the assembler has control of both the configuration and the
lookup (so can match the role name with the appropiate component).
Item 3 could be done using hints (but probably not 2).
However 1, 2 and 3 could be achieved if the assembler is given the ability
to define a mapping of role names to components for each client. So I'd
like to suggest that this ability be part of the framework - i.e. state
that containers should give assemblers this ability (so that component
writers can feel confident that when writing code that assumes 2 and 3
they are not sacrificing reusuability).
Something like:
"Component writers may assume that a container will give the assembler
the ability to specify (uniquely for each client) which component will be
returned whenever a role is looked up. Further a component may receive
role names via the configuration."
Finally I'd also like:
4. metadata be optional. (relying on the assembler if it is missing).
(but that's mainly because I'm lazy).
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
Steve,
yes, what I described is more of an application composed of a hierarchy of
functional units (and that hierarchy, while defined by configuration,
remained static for the applications life)... however I think that avalon
should support this sort of hierarchy because of what happened next with
some of the components that were used in it...
In the example I described below the controller and units were not at the
top or bottom of the hierarchy (the units produced data, so had a
dependence on a DataCollector which had to be unique for each unit)... The
application had a lot of other pieces, some related to the functionality
of the user interface...
The framework (developed in-house) was suitable for such an application
(hierarchy of functional units and scoped names)... Later they thought -
"wouldn't it be good if we could use some of our components in a webapp
since we want the web user-interface to share some functionality with the
application user-interface" (though obviously not the same look-and-feel).
Unfortunately the design of the framework prevented this (it used static
methods to fetch global configuration that would not be global in a
webapp)... [disclaimer: I wasn't around when the framework was designed
:)]
The point is that what is a 'function unit' within an application could
also become a component in a different setting (though as I said not with
the framework that was used).
Basically there are 2 reasons to allow avalon to support using components
as 'functional units' and having name scoping:
1. so that when writing such an application you can re-use existing
components as your functional units.
2. having written such an application, your functional units can be used
as components elsewhere.
I'd like to finish with a rant:
<rant subject="Assembler as God">
[by assembler I'm referring to the person who puts the final application
together - including things like writing the code for a programatically
assembled container (like fortress), and writing a cocoon sitemap].
The framework describes a contract between a component and a container -
this is good for both component writers and container writers... but
components and containers are both subject to the whims of the assembler.
The assembler gets the last say. The assembler puts everything together
to form the final application - choosing components and the container to
suit their needs. [though perhaps not always with a choice of container]
If a component/container isn't flexible enough then the assembler can
choose another (or potentially write one).
I think that this should be recognised in how a component is looked up -
i.e. when a client asks for a particular role, the assembler should be
able to specify exactly what component it gets.
In that respect components only get to demand what they need in terms of
interfaces -- anything else they have to humbly request from the
assembler, and not complain when denied.
e.g.
If a component asks for a tcp connection, then suggests that it should be
SSL - I, as assembler should be able to say "denied: your connection will
be tunnelled via ssh instead" -- of course if the component had requested
a 'secure' connection, the request would have been approved (or not if it
is in a development/testing environment).
Now suppose that the component and the container are conspiring against
me, the assembler - and the component tells the container (via metadata)
that it insists that the connection be SSL, and the container decides to
enforce that... well I could write a small wrapper component that lied to
the container saying that it provided an SSL connection, but instead
simply used another component that provided an unencrypted tcp connection
that happened to go through a VPN tunnel.
I am the assembler, I always win :)
Anyway, the point is that the framework should recognise the role that the
assembler plays and not try to limit the assemblers ability to chose what
components client get for particular roles -- the assembler is the only
one who can see the 'big picture'.
If a component really, really, wants an SSL connection then it can always
embed one inside itself.
[of course metadata can be useful, if the assembler is lazy and the
container has to guess what component to give the client]
</rant>
Robert.
Stephen McConnell wrote:
> Robert:
>
> Thinking-out-load ...
>
> Relative to my current thinking and work I'm currently doing related to
> containerkit, what you are describing below is an application. It's an
> application because you are describing the "content" of a functional
> unit. In the example, your using a single class as the base (but this
> is semi-academic). In effect you are describing a series of type
> profiles based on a single class. Each profile represents the
> association of a base type with criteria concerning the deployment of
> the type. These profiles are named such that each name is unique within
> the application context (which is different to role names in a component
> type context).
>
> Your client component needs to declare a dependecy on the controller
> application and once that has been resolved via lookup, it then get the
> service you want using the profile name as the key in the application
> scope of the controller (or any other application specific method you
> choose). That operation is specific to the application at this time.
> However, there is thinking going on about how application/container
> hierachies could be managed - which would potentially enable your lookup
> operation to be directed to the application in which the name is scoped
> - but that's pure speculation at the moment so don't ask too many
> questions just yet! Like I said ... thinking-out-load.
>
> Hope this helps.
>
> Cheers, Steve.
>
>
> Robert Mouat wrote:
>
> >I have a use case (from previous work I did in a non-avalon framework)
> >that I'm not sure how to reconcile with the current metadata/lookup()
> >proposal...
> >
> >basically there are two issues:
> >1. multiple components coming from the same class (with different configuration).
> >2. passing role names into a component via configuration.
> >
> >The situation is that I have a controller, that controls multiple units
> >(so that they can work together) -- the number of units it controls (and
> >how they work) is specified in the controller's configuration. The units
> >are generally all going to be of the same class but with different
> >configuration (e.g. different ports).
> >
> >so I will have something like:
> >
> ><component id="unit1" class="UnitImpl">
> > <!-- unit1 configuration -->
> ></component>
> >
> ><component id="unit2" class"UnitImpl">
> > <!-- unit2 configuration -->
> ></component>
> >
> ><!-- ... -->
> >
> ><component id="controller" class="UnitController">
> > <!--
> > ...
> > <unit name="unit1"/>
> > <unit name="unit2"/>
> > ...
> > -->
> ></component>
> >
> >(This is perhaps not too dissimilar in concept to a cocoon sitemap).
> >
> >In an ideal situation I'd like the controller to be able to do something
> >like:
> >
> > unit[i] = (Unit) lookup( unitNames[i] );
> >
> >where unitNames[] comes from the configuration and is something like
> > { "unit1", "unit2" /* ... */ }
> >
> >It is impossible for the controller to declare these dependencies in
> >metadata - since they aren't known until assemble time.
> >
> >Now I don't fully understand how the current metadata proposal governs
> >component resolution, but I get the impression that I can't write the
> >above in a container independent way (and hence not in a reusable way)...
> >I could probably use a Selector (e.g. lookup("unit-selector")), but then
> >the Selector would have to be container specific for the same reasons.
> >
> >The reason I'm not sure that this will work is that when I look over the
> >emails regarding metadata/lookup() it seems that the job of the assembler,
> >as far as determining a mapping from role names to components, is absent
> >-- maybe it was just assumed (and not explicitly mentioned).
> >
> >What I'm looking for is some assurance the the job of the assembler isn't
> >going to be replaced by metadata.
> >
> >Am I misunderstanding something about the metadata/lookup() proposal? is
> >it possible to write such a beast in a container independent way?
> >
> >- or -
> >
> >is 'controller' really a block (or the controller+units a single big
> >component)? And it should embed Fortress (or another container), and take
> >in all the configuration for the units as well as it's own configuration?
> >
> >Robert.
> >
> >On Mon, 24 Jun 2002, Berin Loritsch wrote:
> >
> >
> >
> >>Date: Mon, 24 Jun 2002 15:30:49 -0400
> >>From: Berin Loritsch <bl...@apache.org>
> >>Reply-To: Avalon Developers List <av...@jakarta.apache.org>,
> >> bloritsch@apache.org
> >>To: 'Avalon Developers List' <av...@jakarta.apache.org>
> >>Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
> >> 'hints')
> >>
> >>While Stefano has some important points, we do have to bring practice
> >>into view. An abstraction without foundation in reality is doomed to
> >>failure. So let's look at this pragmatically.
> >>
> >>
> >>
> >>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >>>
> >>>Ok, this said, let's move on. I see two different ways of
> >>>looking for a
> >>>component:
> >>>
> >>> 1) I need something that does this.
> >>>
> >>> 2) I need something that does this, and should work in this context
> >>>
> >>>Two real life examples:
> >>>
> >>>1)
> >>> composer: I need a component that implements 'screwdriver'
> >>> componentManager: here it is
> >>>
> >>>2)
> >>> composer: I need a component that implements 'screwdriver'
> >>>and I'll use it on screws of 3 mm of diameter.
> >>> componentManager: here it is
> >>>
> >>>It has been suggested that the working context is just
> >>>another information you pass in the role, so, in our
> >>>examples, we would have an inflation of roles for each
> >>>screwdriver and each possible screw size or size ranges.
> >>>
> >>>Please, tell me, am I the only one who doesn't get a good
> >>>feeling out of this?
> >>>
> >>>
> >>In the hardware realm for ordinary household projects, you
> >>only have to worry about three basic sizes of screwdrivers
> >>and two different types. There are Philips head and Flat
> >>head screwdrivers. They come in three sizes (#1, #2, #3).
> >>For 90% of woodworking projects you use a Philips #2. For 90%
> >>of electrical projects you use a Flathead #2 (or #1).
> >>
> >>The bottom line is that while there are many different
> >>possibilities of roles, only a couple are really necessary in
> >>a system.
> >>
> >>For projects like Cocoon where the Sitemap is not only the
> >>container for its components, but it also chooses the
> >>component necessary for the job, it is really better for the
> >>Sitemap container to choose the component in a Cocoon specific
> >>way.
> >>
> >>What you are accusing Peter and company of doing is not really
> >>any different than what Cocoon does. The lookup might change
> >>from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
> >>but the general outcome is the same. There is *essentially*
> >>ten different roles if we are being true to what it conceptually
> >>is.
> >>
> >>To the pipeline, A generator is a generator is a generator.
> >>To the sitemap, we may have ten different implementations that
> >>we choose from. The *sitemap* chooses which of those 10
> >>generators are used depending on context. Because it is a
> >>container in and of itself, it can do so in any way it chooses.
> >>Effectively each individual Generator performs a different role.
> >>One pulls info from the filesystem, another pulls it from an
> >>external site, and yet another will pull it from a database.
> >>The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
> >>directly request the generator. The sitemap sets the generator.
> >>
> >>So for real practicality's sake, we either have a distinct
> >>role for each of the Generators or we have a smart container.
> >>
> >>Think of it in terms of the Chorus in a theatrical play. They
> >>act as one, but they have their own part to play in the harmony
> >>or narration of the play. There might be three distinct people
> >>on the stage at one time that perform the same general function.
> >>It is the same with the concept of generators in Cocoon.
> >>
> >>Please tell me if I have confused you more than I have clarified
> >>things.
> >>
> >>
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
> >
> > Disclaimer: newbie talking, wishful thinking mode on.
> >
> > If this has been brought up before, my apologies. One of the
> > things I would like to see in Avalon 5 (4.5, x+1, whatever)
> > is documented patterns for integration with other component
> > models (I'm using the word component in a loose sense here).
> > For example, we are using EJBs in other projects, and I think
> > it would be great to have a documented way of approaching
> > these scenarios:
>
> Please, no alarms about Avalon 5.
Sorry, I thought this was posted to the users list....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > If this has been brought up before, my apologies. One of the
> > things I would like to see in Avalon 5 (4.5, x+1, whatever)
> > is documented patterns for integration with other component
> > models (I'm using the word component in a loose sense here).
> > For example, we are using EJBs in other projects, and I think
> > it would be great to have a documented way of approaching
> > these scenarios:
>
> Please, no alarms about Avalon 5.
??? Don't know what you mean by that...
> Now, as to you request for documentation, that can be satisfied
> while we are still in A4.
Ok, although I did say "(4.5, x+1, whatever)".
> There are several approaches we can take. There are several component
> models that Avalon can work with (or within). These include:
>
> * EJBs
> * CORBA
> * Servlets
> * Role Your Own
>
> For something like a servlet architecture, the best approach is
> embedding
> an Avalon container within the servlet. There are two ways you can do
> it. For the simple case where you have one servlet servicing all your
> requests, you have that contain the embedded Avalon container and make
> your calls to that. For a more distributed case, you would bind the
> container to JNDI and have all servlets access it. (Use a special
> purpose
> servlet that exists just to bind the Avalon container).
>
> To use a hybrid environment, where some components are EJBs or CORBA
> components and some are Avalon components, you would have to apply the
> same trick for the distributed servlets. Bind the Avalon container to
> JNDI and access it from all the other components. Unfortunately there
> is no portable way to do that. You can't use EJBs to bind the container
> either because their environment is too constrained (no access to the
> filesystem, no write access to JNDI, etc.).
>
> To use Avalon as your façade to the external EJB/CORBA components you
> *must* use the ServiceManager interface because it returns an Object
> instead of artificially forcing you to implement Component.
>
> For the Role Your Own components, it is your architecture so you have
> to decide.
>
> Hopefully this will get you pointed in the right direction. If there
> is anyone willing to donate some detailed instructions on how to best
> implement this, the Avalon team would be more than happy to post those
> instructions on the web.
This is good info, hopefully someone who knows how to do it will
take the time and make it the beginnings of documentation for the
use cases I enumerated.
Thanks,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
>
> Disclaimer: newbie talking, wishful thinking mode on.
>
> If this has been brought up before, my apologies. One of the
> things I would like to see in Avalon 5 (4.5, x+1, whatever)
> is documented patterns for integration with other component
> models (I'm using the word component in a loose sense here).
> For example, we are using EJBs in other projects, and I think
> it would be great to have a documented way of approaching
> these scenarios:
Please, no alarms about Avalon 5.
Now, as to you request for documentation, that can be satisfied
while we are still in A4.
>
> * Components are implemented as Avalon components, EJBs are shallow
> bridges to them.
> * Components are implemented as EJBs, Avalon components serve as
> interfaces to the components from the non-EJB world (is this doable
> at all?).
> * Hybrid mode: some components are EJBs, some are Avalonized.
>
> The EJB model is just an example here, it would be nice to
> have well documented patterns for doing this integration with
> Servlets, CORBA, COM, etc. I don't know all of these very
> well, so it may be that it is simply not possible to have
> this degree of integration, but I think it would be very good
> to have documented patterns for Servlets and EJBs at least.
>
> Best regards, and thanks for a solid architecture.
:)
There are several approaches we can take. There are several component
models that Avalon can work with (or within). These include:
* EJBs
* CORBA
* Servlets
* Role Your Own
For something like a servlet architecture, the best approach is
embedding
an Avalon container within the servlet. There are two ways you can do
it. For the simple case where you have one servlet servicing all your
requests, you have that contain the embedded Avalon container and make
your calls to that. For a more distributed case, you would bind the
container to JNDI and have all servlets access it. (Use a special
purpose
servlet that exists just to bind the Avalon container).
To use a hybrid environment, where some components are EJBs or CORBA
components and some are Avalon components, you would have to apply the
same trick for the distributed servlets. Bind the Avalon container to
JNDI and access it from all the other components. Unfortunately there
is no portable way to do that. You can't use EJBs to bind the container
either because their environment is too constrained (no access to the
filesystem, no write access to JNDI, etc.).
To use Avalon as your façade to the external EJB/CORBA components you
*must* use the ServiceManager interface because it returns an Object
instead of artificially forcing you to implement Component.
For the Role Your Own components, it is your architecture so you have
to decide.
Hopefully this will get you pointed in the right direction. If there
is anyone willing to donate some detailed instructions on how to best
implement this, the Avalon team would be more than happy to post those
instructions on the web.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon 5 and integration
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
Disclaimer: newbie talking, wishful thinking mode on.
If this has been brought up before, my apologies. One of the things
I would like to see in Avalon 5 (4.5, x+1, whatever) is documented
patterns for integration with other component models (I'm using the
word component in a loose sense here). For example, we are using
EJBs in other projects, and I think it would be great to have a
documented way of approaching these scenarios:
* Components are implemented as Avalon components, EJBs are shallow
bridges to them.
* Components are implemented as EJBs, Avalon components serve as
interfaces to the components from the non-EJB world (is this doable
at all?).
* Hybrid mode: some components are EJBs, some are Avalonized.
The EJB model is just an example here, it would be nice to have well
documented patterns for doing this integration with Servlets, CORBA,
COM, etc. I don't know all of these very well, so it may be that it
is simply not possible to have this degree of integration, but I
think it would be very good to have documented patterns for Servlets
and EJBs at least.
Best regards, and thanks for a solid architecture.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Stephen McConnell <mc...@osm.net>.
Robert:
Thinking-out-load ...
Relative to my current thinking and work I'm currently doing related to
containerkit, what you are describing below is an application. It's an
application because you are describing the "content" of a functional
unit. In the example, your using a single class as the base (but this
is semi-academic). In effect you are describing a series of type
profiles based on a single class. Each profile represents the
association of a base type with criteria concerning the deployment of
the type. These profiles are named such that each name is unique within
the application context (which is different to role names in a component
type context).
Your client component needs to declare a dependecy on the controller
application and once that has been resolved via lookup, it then get the
service you want using the profile name as the key in the application
scope of the controller (or any other application specific method you
choose). That operation is specific to the application at this time.
However, there is thinking going on about how application/container
hierachies could be managed - which would potentially enable your lookup
operation to be directed to the application in which the name is scoped
- but that's pure speculation at the moment so don't ask too many
questions just yet! Like I said ... thinking-out-load.
Hope this helps.
Cheers, Steve.
Robert Mouat wrote:
>I have a use case (from previous work I did in a non-avalon framework)
>that I'm not sure how to reconcile with the current metadata/lookup()
>proposal...
>
>basically there are two issues:
>1. multiple components coming from the same class (with different configuration).
>2. passing role names into a component via configuration.
>
>The situation is that I have a controller, that controls multiple units
>(so that they can work together) -- the number of units it controls (and
>how they work) is specified in the controller's configuration. The units
>are generally all going to be of the same class but with different
>configuration (e.g. different ports).
>
>so I will have something like:
>
><component id="unit1" class="UnitImpl">
> <!-- unit1 configuration -->
></component>
>
><component id="unit2" class"UnitImpl">
> <!-- unit2 configuration -->
></component>
>
><!-- ... -->
>
><component id="controller" class="UnitController">
> <!--
> ...
> <unit name="unit1"/>
> <unit name="unit2"/>
> ...
> -->
></component>
>
>(This is perhaps not too dissimilar in concept to a cocoon sitemap).
>
>In an ideal situation I'd like the controller to be able to do something
>like:
>
> unit[i] = (Unit) lookup( unitNames[i] );
>
>where unitNames[] comes from the configuration and is something like
> { "unit1", "unit2" /* ... */ }
>
>It is impossible for the controller to declare these dependencies in
>metadata - since they aren't known until assemble time.
>
>Now I don't fully understand how the current metadata proposal governs
>component resolution, but I get the impression that I can't write the
>above in a container independent way (and hence not in a reusable way)...
>I could probably use a Selector (e.g. lookup("unit-selector")), but then
>the Selector would have to be container specific for the same reasons.
>
>The reason I'm not sure that this will work is that when I look over the
>emails regarding metadata/lookup() it seems that the job of the assembler,
>as far as determining a mapping from role names to components, is absent
>-- maybe it was just assumed (and not explicitly mentioned).
>
>What I'm looking for is some assurance the the job of the assembler isn't
>going to be replaced by metadata.
>
>Am I misunderstanding something about the metadata/lookup() proposal? is
>it possible to write such a beast in a container independent way?
>
>- or -
>
>is 'controller' really a block (or the controller+units a single big
>component)? And it should embed Fortress (or another container), and take
>in all the configuration for the units as well as it's own configuration?
>
>Robert.
>
>On Mon, 24 Jun 2002, Berin Loritsch wrote:
>
>
>
>>Date: Mon, 24 Jun 2002 15:30:49 -0400
>>From: Berin Loritsch <bl...@apache.org>
>>Reply-To: Avalon Developers List <av...@jakarta.apache.org>,
>> bloritsch@apache.org
>>To: 'Avalon Developers List' <av...@jakarta.apache.org>
>>Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
>> 'hints')
>>
>>While Stefano has some important points, we do have to bring practice
>>into view. An abstraction without foundation in reality is doomed to
>>failure. So let's look at this pragmatically.
>>
>>
>>
>>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>>
>>>Ok, this said, let's move on. I see two different ways of
>>>looking for a
>>>component:
>>>
>>> 1) I need something that does this.
>>>
>>> 2) I need something that does this, and should work in this context
>>>
>>>Two real life examples:
>>>
>>>1)
>>> composer: I need a component that implements 'screwdriver'
>>> componentManager: here it is
>>>
>>>2)
>>> composer: I need a component that implements 'screwdriver'
>>>and I'll use it on screws of 3 mm of diameter.
>>> componentManager: here it is
>>>
>>>It has been suggested that the working context is just
>>>another information you pass in the role, so, in our
>>>examples, we would have an inflation of roles for each
>>>screwdriver and each possible screw size or size ranges.
>>>
>>>Please, tell me, am I the only one who doesn't get a good
>>>feeling out of this?
>>>
>>>
>>In the hardware realm for ordinary household projects, you
>>only have to worry about three basic sizes of screwdrivers
>>and two different types. There are Philips head and Flat
>>head screwdrivers. They come in three sizes (#1, #2, #3).
>>For 90% of woodworking projects you use a Philips #2. For 90%
>>of electrical projects you use a Flathead #2 (or #1).
>>
>>The bottom line is that while there are many different
>>possibilities of roles, only a couple are really necessary in
>>a system.
>>
>>For projects like Cocoon where the Sitemap is not only the
>>container for its components, but it also chooses the
>>component necessary for the job, it is really better for the
>>Sitemap container to choose the component in a Cocoon specific
>>way.
>>
>>What you are accusing Peter and company of doing is not really
>>any different than what Cocoon does. The lookup might change
>>from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
>>but the general outcome is the same. There is *essentially*
>>ten different roles if we are being true to what it conceptually
>>is.
>>
>>To the pipeline, A generator is a generator is a generator.
>>To the sitemap, we may have ten different implementations that
>>we choose from. The *sitemap* chooses which of those 10
>>generators are used depending on context. Because it is a
>>container in and of itself, it can do so in any way it chooses.
>>Effectively each individual Generator performs a different role.
>>One pulls info from the filesystem, another pulls it from an
>>external site, and yet another will pull it from a database.
>>The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
>>directly request the generator. The sitemap sets the generator.
>>
>>So for real practicality's sake, we either have a distinct
>>role for each of the Generators or we have a smart container.
>>
>>Think of it in terms of the Chorus in a theatrical play. They
>>act as one, but they have their own part to play in the harmony
>>or narration of the play. There might be three distinct people
>>on the stage at one time that perform the same general function.
>>It is the same with the concept of generators in Cocoon.
>>
>>Please tell me if I have confused you more than I have clarified
>>things.
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Robert Mouat <ro...@mouat.net>.
I have a use case (from previous work I did in a non-avalon framework)
that I'm not sure how to reconcile with the current metadata/lookup()
proposal...
basically there are two issues:
1. multiple components coming from the same class (with different configuration).
2. passing role names into a component via configuration.
The situation is that I have a controller, that controls multiple units
(so that they can work together) -- the number of units it controls (and
how they work) is specified in the controller's configuration. The units
are generally all going to be of the same class but with different
configuration (e.g. different ports).
so I will have something like:
<component id="unit1" class="UnitImpl">
<!-- unit1 configuration -->
</component>
<component id="unit2" class"UnitImpl">
<!-- unit2 configuration -->
</component>
<!-- ... -->
<component id="controller" class="UnitController">
<!--
...
<unit name="unit1"/>
<unit name="unit2"/>
...
-->
</component>
(This is perhaps not too dissimilar in concept to a cocoon sitemap).
In an ideal situation I'd like the controller to be able to do something
like:
unit[i] = (Unit) lookup( unitNames[i] );
where unitNames[] comes from the configuration and is something like
{ "unit1", "unit2" /* ... */ }
It is impossible for the controller to declare these dependencies in
metadata - since they aren't known until assemble time.
Now I don't fully understand how the current metadata proposal governs
component resolution, but I get the impression that I can't write the
above in a container independent way (and hence not in a reusable way)...
I could probably use a Selector (e.g. lookup("unit-selector")), but then
the Selector would have to be container specific for the same reasons.
The reason I'm not sure that this will work is that when I look over the
emails regarding metadata/lookup() it seems that the job of the assembler,
as far as determining a mapping from role names to components, is absent
-- maybe it was just assumed (and not explicitly mentioned).
What I'm looking for is some assurance the the job of the assembler isn't
going to be replaced by metadata.
Am I misunderstanding something about the metadata/lookup() proposal? is
it possible to write such a beast in a container independent way?
- or -
is 'controller' really a block (or the controller+units a single big
component)? And it should embed Fortress (or another container), and take
in all the configuration for the units as well as it's own configuration?
Robert.
On Mon, 24 Jun 2002, Berin Loritsch wrote:
> Date: Mon, 24 Jun 2002 15:30:49 -0400
> From: Berin Loritsch <bl...@apache.org>
> Reply-To: Avalon Developers List <av...@jakarta.apache.org>,
> bloritsch@apache.org
> To: 'Avalon Developers List' <av...@jakarta.apache.org>
> Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
> 'hints')
>
> While Stefano has some important points, we do have to bring practice
> into view. An abstraction without foundation in reality is doomed to
> failure. So let's look at this pragmatically.
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Ok, this said, let's move on. I see two different ways of
> > looking for a
> > component:
> >
> > 1) I need something that does this.
> >
> > 2) I need something that does this, and should work in this context
> >
> > Two real life examples:
> >
> > 1)
> > composer: I need a component that implements 'screwdriver'
> > componentManager: here it is
> >
> > 2)
> > composer: I need a component that implements 'screwdriver'
> > and I'll use it on screws of 3 mm of diameter.
> > componentManager: here it is
> >
> > It has been suggested that the working context is just
> > another information you pass in the role, so, in our
> > examples, we would have an inflation of roles for each
> > screwdriver and each possible screw size or size ranges.
> >
> > Please, tell me, am I the only one who doesn't get a good
> > feeling out of this?
>
> In the hardware realm for ordinary household projects, you
> only have to worry about three basic sizes of screwdrivers
> and two different types. There are Philips head and Flat
> head screwdrivers. They come in three sizes (#1, #2, #3).
> For 90% of woodworking projects you use a Philips #2. For 90%
> of electrical projects you use a Flathead #2 (or #1).
>
> The bottom line is that while there are many different
> possibilities of roles, only a couple are really necessary in
> a system.
>
> For projects like Cocoon where the Sitemap is not only the
> container for its components, but it also chooses the
> component necessary for the job, it is really better for the
> Sitemap container to choose the component in a Cocoon specific
> way.
>
> What you are accusing Peter and company of doing is not really
> any different than what Cocoon does. The lookup might change
> from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
> but the general outcome is the same. There is *essentially*
> ten different roles if we are being true to what it conceptually
> is.
>
> To the pipeline, A generator is a generator is a generator.
> To the sitemap, we may have ten different implementations that
> we choose from. The *sitemap* chooses which of those 10
> generators are used depending on context. Because it is a
> container in and of itself, it can do so in any way it chooses.
> Effectively each individual Generator performs a different role.
> One pulls info from the filesystem, another pulls it from an
> external site, and yet another will pull it from a database.
> The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
> directly request the generator. The sitemap sets the generator.
>
> So for real practicality's sake, we either have a distinct
> role for each of the Generators or we have a smart container.
>
> Think of it in terms of the Chorus in a theatrical play. They
> act as one, but they have their own part to play in the harmony
> or narration of the play. There might be three distinct people
> on the stage at one time that perform the same general function.
> It is the same with the concept of generators in Cocoon.
>
> Please tell me if I have confused you more than I have clarified
> things.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Posted by Berin Loritsch <bl...@apache.org>.
While Stefano has some important points, we do have to bring practice
into view. An abstraction without foundation in reality is doomed to
failure. So let's look at this pragmatically.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Ok, this said, let's move on. I see two different ways of
> looking for a
> component:
>
> 1) I need something that does this.
>
> 2) I need something that does this, and should work in this context
>
> Two real life examples:
>
> 1)
> composer: I need a component that implements 'screwdriver'
> componentManager: here it is
>
> 2)
> composer: I need a component that implements 'screwdriver'
> and I'll use it on screws of 3 mm of diameter.
> componentManager: here it is
>
> It has been suggested that the working context is just
> another information you pass in the role, so, in our
> examples, we would have an inflation of roles for each
> screwdriver and each possible screw size or size ranges.
>
> Please, tell me, am I the only one who doesn't get a good
> feeling out of this?
In the hardware realm for ordinary household projects, you
only have to worry about three basic sizes of screwdrivers
and two different types. There are Philips head and Flat
head screwdrivers. They come in three sizes (#1, #2, #3).
For 90% of woodworking projects you use a Philips #2. For 90%
of electrical projects you use a Flathead #2 (or #1).
The bottom line is that while there are many different
possibilities of roles, only a couple are really necessary in
a system.
For projects like Cocoon where the Sitemap is not only the
container for its components, but it also chooses the
component necessary for the job, it is really better for the
Sitemap container to choose the component in a Cocoon specific
way.
What you are accusing Peter and company of doing is not really
any different than what Cocoon does. The lookup might change
from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
but the general outcome is the same. There is *essentially*
ten different roles if we are being true to what it conceptually
is.
To the pipeline, A generator is a generator is a generator.
To the sitemap, we may have ten different implementations that
we choose from. The *sitemap* chooses which of those 10
generators are used depending on context. Because it is a
container in and of itself, it can do so in any way it chooses.
Effectively each individual Generator performs a different role.
One pulls info from the filesystem, another pulls it from an
external site, and yet another will pull it from a database.
The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
directly request the generator. The sitemap sets the generator.
So for real practicality's sake, we either have a distinct
role for each of the Generators or we have a smart container.
Think of it in terms of the Chorus in a theatrical play. They
act as one, but they have their own part to play in the harmony
or narration of the play. There might be three distinct people
on the stage at one time that perform the same general function.
It is the same with the concept of generators in Cocoon.
Please tell me if I have confused you more than I have clarified
things.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 07:36 PM 6/24/2002 +0200, you wrote:
>Ok, this said, let's move on. I see two different ways of looking for a
>component:
>
> 1) I need something that does this.
>
> 2) I need something that does this, and should work in this context
I dont see any difference between the above two except the number of
contraints they satisfy.
1) Need X that
* satisfies the "does this" constraint (usually type)
2) Need X that
* satisfies the "does this" constraint (usually type)
* satisfies the work in this context constraint
The number of constraints in a dependency is independent of the name you
give to dependency.
>It has been suggested that the working context is just another
>information you pass in the role, so, in our examples, we would have an
>inflation of roles for each screwdriver and each possible screw size or
>size ranges.
Each dependency can have a different name or not - up to writer of consumer
component. I would never create multiple work interfaces to specify
different dependecies.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 11:45 AM 6/23/2002 +0200, you wrote:
> >Peter Donald wrote:
> >
> > > According to your own analysis there is no distinction except for metadata.
> >
> >Please, define 'component metadata' before I can answer your question.
>
> In abstract terms, data associated with a component type that declares
> * what component requires to work
> * what component offers other components
> * the environment in which component executes (though strictly speaking
> this is not needed).
>
> In physical terms it means declaring the components that the component
> depends upon or exports and also declaring its lifecycle style and possibly
> other container specific things.
Ok, I have enough information to answer your question.
You say that blocks and components are the same concept except for
metadata.
Given your above definition, I agree.
- o -
Ok, this said, let's move on. I see two different ways of looking for a
component:
1) I need something that does this.
2) I need something that does this, and should work in this context
Two real life examples:
1)
composer: I need a component that implements 'screwdriver'
componentManager: here it is
2)
composer: I need a component that implements 'screwdriver' and I'll use
it on screws of 3 mm of diameter.
componentManager: here it is
It has been suggested that the working context is just another
information you pass in the role, so, in our examples, we would have an
inflation of roles for each screwdriver and each possible screw size or
size ranges.
Please, tell me, am I the only one who doesn't get a good feeling out of
this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 11:45 AM 6/23/2002 +0200, you wrote:
>Peter Donald wrote:
>
> > According to your own analysis there is no distinction except for metadata.
>
>Please, define 'component metadata' before I can answer your question.
In abstract terms, data associated with a component type that declares
* what component requires to work
* what component offers other components
* the environment in which component executes (though strictly speaking
this is not needed).
In physical terms it means declaring the components that the component
depends upon or exports and also declaring its lifecycle style and possibly
other container specific things.
> Leo (A Cocoon developer) saids a killer feature would be to change cocoon
> > to not be directly referentiable.
>
>Stefano (another Cocoon developer) asks how this is possible if the
>direct referencing of components is hardcoded into the sitemap
>semantics.
He assumes that the all components are indirectly referencing other
components, it just happens that the components are directly mapped into
local namespace unless otherwise indicated.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> > Leo (A Cocoon developer) saids a killer feature would be to change
> > cocoon to not be directly referentiable.
>
> Stefano (another Cocoon developer) asks how this is possible
> if the direct referencing of components is hardcoded into the
> sitemap semantics.
Leo (the Cocoon "developer" first mentioned, although strictly speaking
he's not a committer to Cocoon and has contributes very few patches)
wonders what "directly referentiable" means.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> According to your own analysis there is no distinction except for metadata.
Please, define 'component metadata' before I can answer your question.
> > block -> an avalon-lifecycle-aware polymorphic object, versionned,
> >fully reentrant, sharable, not directly referentiable
>
> Thats not entirely accurate. There is no constraint that a block be
> reentrant or sharable nor has there ever been. It is left up to developer
> and assembler to decide these things.
>
> > component -> an avalon-lifecycle-aware polymorphic object, directly
> >referentiable
>
> Leo (A Cocoon developer) saids a killer feature would be to change cocoon
> to not be directly referentiable.
Stefano (another Cocoon developer) asks how this is possible if the
direct referencing of components is hardcoded into the sitemap
semantics.
> Given the above points do you still think there is a non-academic
> distinction between Components and Blocks?
I will answer this after you define 'component metadata'.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 01:40 AM 6/21/2002 +0200, you wrote:
>Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
>bricks. Where polymorphic objects.
>
>Blocks had version, metadata dependencies, they were thread-safe, they
>were big.
>
>I remember a pretty heated discussion with Peter about the size of
>blocks. That time I even managed to change his mind ;-)
And the real-world changed it back. A Block is just a component with
metainfo associated with it - much like cocoons components.
Gosh, things would be easier if you didn't deprecate the concept of
>'block' and wanted to use the same name for two different things.
According to your own analysis there is no distinction except for metadata.
> block -> an avalon-lifecycle-aware polymorphic object, versionned,
>fully reentrant, sharable, not directly referentiable
Thats not entirely accurate. There is no constraint that a block be
reentrant or sharable nor has there ever been. It is left up to developer
and assembler to decide these things.
> component -> an avalon-lifecycle-aware polymorphic object, directly
>referentiable
Leo (A Cocoon developer) saids a killer feature would be to change cocoon
to not be directly referentiable.
Given the above points do you still think there is a non-academic
distinction between Components and Blocks?
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Is that clear enough?
Well... you statement would not work as vision for what Avalon is...
=;o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Sunday, June 23, 2002 11:39 AM
> To: Avalon Developers List
> Subject: Re: [desperate plea] RE: The need for 'hints'
>
>
> Paulo Gaspar wrote:
> >
> > > Thats fine as long as the one abusing the framework does not start
> > > inflicting others with their design choices. Then they go from hurting
> > > themselves to hurting others.
> >
> > Of course. But that is where I miss a cristal clear vision of what
> > Avalon should be - and one much less abstract than the current ones.
> >
> > If you have such vision in place you can point it to that kind of
> > "abuser" and rapidly stop the noise. Otherwise a lot of energy will
> > be wasted, including the "abuser"'s energy, because he will take
> > longer to realize what he can get and what he can NOT get from
> > Avalon.
>
> Exactly.
>
> To be entirely honest, I personally don't give a damn if Cocoon uses
> Avalon 4, Avalon 5 or PetersGoofyFramework, as long as it does what we
> want and we can have enough arguments to convince people to jump and how
> high.
>
> Is that clear enough?
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Paulo Gaspar wrote:
>
> > Thats fine as long as the one abusing the framework does not start
> > inflicting others with their design choices. Then they go from hurting
> > themselves to hurting others.
>
> Of course. But that is where I miss a cristal clear vision of what
> Avalon should be - and one much less abstract than the current ones.
>
> If you have such vision in place you can point it to that kind of
> "abuser" and rapidly stop the noise. Otherwise a lot of energy will
> be wasted, including the "abuser"'s energy, because he will take
> longer to realize what he can get and what he can NOT get from
> Avalon.
Exactly.
To be entirely honest, I personally don't give a damn if Cocoon uses
Avalon 4, Avalon 5 or PetersGoofyFramework, as long as it does what we
want and we can have enough arguments to convince people to jump and how
high.
Is that clear enough?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Thats fine as long as the one abusing the framework does not start
> inflicting others with their design choices. Then they go from hurting
> themselves to hurting others.
Of course. But that is where I miss a cristal clear vision of what
Avalon should be - and one much less abstract than the current ones.
If you have such vision in place you can point it to that kind of
"abuser" and rapidly stop the noise. Otherwise a lot of energy will
be wasted, including the "abuser"'s energy, because he will take
longer to realize what he can get and what he can NOT get from
Avalon.
Regards,
Paulo
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, June 21, 2002 1:54 AM
> To: Avalon Developers List
> Subject: RE: [desperate plea] RE: The need for 'hints'
>
>
> At 01:24 PM 6/20/2002 +0200, you wrote:
> >I agree.
> >
> >Avalon should be as "abusable" as possible.
> >
> >One can always have a strict layer and an abusable one, or
> >can we not? Each project would use the most convenient one.
>
> Thats fine as long as the one abusing the framework does not start
> inflicting others with their design choices. Then they go from hurting
> themselves to hurting others.
>
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 01:24 PM 6/20/2002 +0200, you wrote:
>I agree.
>
>Avalon should be as "abusable" as possible.
>
>One can always have a strict layer and an abusable one, or
>can we not? Each project would use the most convenient one.
Thats fine as long as the one abusing the framework does not start
inflicting others with their design choices. Then they go from hurting
themselves to hurting others.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
*coughs*...
> This is an interesting history lesson - really interesting! I'm holding
> on to my objections to the points noted above, but my objections are not
> really relevant to the fundimentals of your post. To me those
> fundimentals your are raising can be distilled down to the recognition
> of two different needs and the observation the these needs have been
> folded together in the context of mutual interests - but in doing so,
> the longer term implication have to some extend been compromised
> something. Was the compromise justified - my guess is yes - after all
> Avalon is here today and it is the best framework I know of -
> compromises inclusive.
...okay, so I missed Stefano's intentions here. This sums up rather
nicely what I said rather clumsily.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stephen McConnell <mc...@osm.net>.
Stefano Mazzocchi wrote:
>Leo Sutic wrote:
>
>>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>>
>>>Anyway, I'm changing my -1 to the removal of
>>>lookup(role,hint) to a +0 not to interfere with A5.
>>>
>>Replacing your -1 with mine.
>>
>>
>>>As for Berin's proposal, I think that the use cases you
>>>outlined, not all of them belong to Avalon.
>>>
>>Container portability is good and all, but it forces the
>>concept of what a component is to become much narrower.
>>
>
>I'll tell you the whole truth: the very first Avalon design didn't have
>components at all.
>
>Shoking my town :)
>
>Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
>bricks. Where polymorphic objects.
>
sounds good!
>
>
>Blocks had version, metadata dependencies, they were thread-safe, they
>were big.
>
>I remember a pretty heated discussion with Peter about the size of
>blocks. That time I even managed to change his mind ;-)
>
>Components were introduced later and were introduced mostly because the
>block patterns could be used inside the blocks as well, but where
>portability was not an issue anymore.
>
>So, we had the big reusable/sharable pieces called Blocks and the small
>pieces called Components.
>
>In short, Components were classes++, classes that followed the Avalon
>model. Since in java you want to the ability to instantiate a particular
>class, the need for hints emerged for Components (never for blocks!).
>Result: ComponentSelector.
>
>At that point I left this community for personal reasons.
>
>I come back a while after and:
>
> 1) blocks are deprecated
> 2) components are becoming blocks
> 3) direct component instantiation is considered harmful
>
>Without even noticing, the pure-COP promoters are going backwards: we
>were there already, you simply changed the name of 'block' to
>'component'.
>
Ummm, permission to raise an objection ... but I'm going to continue
reading first! :-)
>
>>In Cocoon, a component can be something very small,
>>and in A5, a component will be something quite big.
>>
Umm, another option raised .. looking at my code base I'm using some
very very small potential A5 components - and a supporting container of
no significant impact in terms of size. But lets keeps reading.
>>
>
>Gosh, things would be easier if you didn't deprecate the concept of
>'block' and wanted to use the same name for two different things.
>
> block -> an avalon-lifecycle-aware polymorphic object, versionned,
>fully reentrant, sharable, not directly referentiable
>
> component -> an avalon-lifecycle-aware polymorphic object, directly
>referentiable
>
That changes my take a little - both are polymorphic, the differntiation
your making between block and component is that a component can be
references directly and is not associted with a version. Option to
object to the prev. assertion still in hand - but this getting more
engaging.
>
>
>It's evident why we wan't find agreement on how to lookup components:
>
> lookup(role)
>
>returns a Block, while
>
> lookup(role, hint)
>
>returns a Component.
>
Ummm, thinking aloud ... lookup( role ) returns a component (the thing
your calling a block) and lookup( something, else ) returns an object
that looks and feels and smells like a component.
>
>
>Cocoon, being itself block-like, references components. This is why it
>needs the ability to reference them directly.
>
>Phoenix/Merlin, on the other hand, being block containers, don't like
>hints because blocks are not directly referentiable (nor they should
>be!)
>
Thinking to myself about the rational for Merlin in the first place ..
the ability to componse and execute a component without the overhead of
"block" a.k.a. Phoenix .. the ability to do things automatically, the
abilty to embed components and really use components whereever you want
to use them in a really free-flow manner ... what's the differnence
between a block (Phoenix style) and a component - the difference is the
contract. Yes - Merlin is a container that deals with well-formed
components, so in your defintion, yes - Merlin is dealing with blocks.
>
>
>*THIS* is, IMO, the biggest design mistake done during my absence: you
>merged two different things into one, without understanding that they
>were totally different and they only thing they shared was
>avalon-lifecycle awareness.
>
>
I'm with you.
Lifecycle awarness yes - comparable semantics no.
>
>>I'm not sure if I like that change. Much of what used
>>to be "applications using the Avalon framework" are now
>>so small that they would be individual components.
>>Don't ignore the small people, please!
>>
>
>I agree. We should not.
>
And we are not!
Considerable time, effort, energy is going into solving this.
>>Don't let Avalon
>>become something that is a heavyweight "for big jobs
>>only" framework. I'm sure there's a need for being able
>>to put small stuff into a container and have it pooled /
>>managed. That was the beauty of A4.
>>
>
>>I'm sure we can find something that allows Avalon to scale
>>from small to big stuff.
>>
>
>Hopefully the above will bring context.
>
>
>>As for the argument of use and abuse of Avalon, if someone
>>can take this framework, and produce a usable product with
>>it, how can we call that "abuse"?
>>
>
>No, careful. Cocoon is block-like and required special treatment of
>internal components. That pushed more and more pressure on the handling
>on 'components' (using the terminology above, not the current avalon
>one) that twisted the clean design of Avalon.
>
>Removing the 'block' pillar forced too much pressure on the current
>concept of Component, leading to 'abuse' of patterns and the creation of
>inelegant solutions (like ComponentSelector, for example, which nobody
>ever liked but it was approved for need)
>
Given equality between your defintion of block and my idea of the
well-formed component, I do think there is a brindge between the two.
Firstly it requires recognition of the differences - which your
outlined at the beginning of this email. Secondly it requires
seperation. Our immediate challenge in this respect is the extent of
transparancy than can be achieved though implementation.
>>The way it is used in
>>Cocoon may not be what we consider proper and beautiful,
>>but it remains a fact that people have found Avalon to be
>>very useful that way.
>>
>
>Yes, there is definately the need for two different kinds of polymorphic
>composition: direct and indirect.
>
Yes.
>Direct is for small things that are
>not sharable nor interoperable, most of the time, application-specific,
>indirect is for bigger things, sharable, interoperable and fully
>reentrant.
>
Yes.
(I repeating myself - eeek!)
>>Coming and saying "abuse! That's not
>>how we want you to use our framework" has quite a high
>>piss-off factor, migration path or not.
>>
>
>Unless you clearly show why.
>
>
>>>I call for a restate of the Avalon's project charter!
>>>
>>OK, so what do you propose we change it to?
>>
>
>"restate" in my vocabulary means: 'state again'.
>
>I did in my previous email :)
>
>Hope this helps giving more context.
>
>
This is an interesting history lesson - really interesting! I'm holding
on to my objections to the points noted above, but my objections are not
really relevant to the fundimentals of your post. To me those
fundimentals your are raising can be distilled down to the recognition
of two different needs and the observation the these needs have been
folded together in the context of mutual interests - but in doing so,
the longer term implication have to some extend been compromised
something. Was the compromise justified - my guess is yes - after all
Avalon is here today and it is the best framework I know of -
compromises inclusive.
Moving onto Stefano's next email ....
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
> Shoking my town :)
>
> Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
> bricks. Where polymorphic objects.
>
> Blocks had version, metadata dependencies, they were thread-safe, they
> were big.
>
> I remember a pretty heated discussion with Peter about the size of
> blocks. That time I even managed to change his mind ;-)
>
> Components were introduced later and were introduced mostly because the
> block patterns could be used inside the blocks as well, but where
> portability was not an issue anymore.
hmm. But reuse of the smaller pieces is also nice, even if they're not
threadsafe or depedenent on other pieces.
> So, we had the big reusable/sharable pieces called Blocks and the small
> pieces called Components.
>
> In short, Components were classes++, classes that followed the Avalon
> model. Since in java you want to the ability to instantiate a particular
> class, the need for hints emerged for Components (never for blocks!).
> Result: ComponentSelector.
>
> At that point I left this community for personal reasons.
>
> I come back a while after and:
>
> 1) blocks are deprecated
nah, that's the marker interface.
> 2) components are becoming blocks
> 3) direct component instantiation is considered harmful
>
> Without even noticing, the pure-COP promoters are going backwards: we
> were there already, you simply changed the name of 'block' to
> 'component'.
I don't think so. A lot more has been changed.
> > In Cocoon, a component can be something very small,
> > and in A5, a component will be something quite big.
>
> Gosh, things would be easier if you didn't deprecate the concept of
> 'block' and wanted to use the same name for two different things.
>
> block -> an avalon-lifecycle-aware polymorphic object, versionned,
> fully reentrant, sharable, not directly referentiable
example: implementation of FTP, POP, ...
why are these "not directly referentiable"? Whole point of stuff like
JMX, SOAP, JNDI is to enable that.
> component -> an avalon-lifecycle-aware polymorphic object, directly
> referentiable
example: any java object with appropriate lifecycle.
> It's evident why we wan't find agreement on how to lookup components:
>
> lookup(role)
>
> returns a Block, while
>
> lookup(role, hint)
>
> returns a Component.
hmm. You mean we need different lookup mechanisms because at one
granularity (blocks) there is stuff like policy, metainfo, etc, and at
the other one (components), there isn't?
- why would a lookup mechanism be coupled to arbitraty granularity?
- why would a lookup mechanism be coupled to policy?
- why is it that where the metainfo stuff is actually in use, it is
about components instead of blocks?
> Cocoon, being itself block-like, references components. This is why it
> needs the ability to reference them directly.
what? It references components so it needs to reference them directly?
> Phoenix/Merlin, on the other hand, being block containers, don't like
> hints because blocks are not directly referentiable (nor they should
> be!)
why shouldn't they be?
Phoenix couldn't care less if you were to use hints to lookup an
application. It would work just as well (or badly, depending on your
viewpoint) as it does in cocoon.
> *THIS* is, IMO, the biggest design mistake done during my absence: you
> merged two different things into one, without understanding that they
> were totally different and they only thing they shared was
> avalon-lifecycle awareness.
the ComponentManager is part of the avalon lifecycle, isn't it? Are you
saying it shouldn't be?
> > I'm sure we can find something that allows Avalon to scale
> > from small to big stuff.
>
> Hopefully the above will bring context.
hmm. I'm still sure we can find a lookup mechanism that can be part of
the lifecycle, that can scale from as-tiny-as-possible to
as-big-as-can-be-in-JVM.
> No, careful. Cocoon is block-like and required special treatment of
> internal components. That pushed more and more pressure on the handling
> on 'components' (using the terminology above, not the current avalon
> one) that twisted the clean design of Avalon.
>
> Removing the 'block' pillar forced too much pressure on the current
> concept of Component, leading to 'abuse' of patterns and the creation of
> inelegant solutions (like ComponentSelector, for example, which nobody
> ever liked but it was approved for need)
I have this integrated application where everything that is not data is
an avalon component (current definition). Among other things, it
includes a mail server, a database layer, persistence facilities, web
server, etc. Those are avalon blocks (==components, ==.bars), they run
within phoenix, packaged into three layers (backend, middleware,
frontend) and thus three server applications (==blocks, ==components,
==.sars).
Within those blocks are avalon components like MimeMessageBuilder,
QueryBuilder, QueryTransformer, DataSource, TemplateParser. Each of the
blocks uses its own (very simple) container (similar to tweety, but with
pooling and some other stuff) to manage those components.
So basically the separation you ment, not?
The key is, they all happily use the same ComponentManager (no Selector,
no release in use). And they're all versioned and directly
referentiable.
> > Coming and saying "abuse! That's not
> > how we want you to use our framework" has quite a high
> > piss-off factor, migration path or not.
>
> Unless you clearly show why.
I wonder...
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Peter Royal <pr...@apache.org>.
On Thursday 20 June 2002 07:40 pm, Stefano Mazzocchi wrote:
> I'll tell you the whole truth: the very first Avalon design didn't have
> components at all.
<snip-avalon-history/>
Wow! Thats for sharing that!
> I come back a while after and:
>
> 1) blocks are deprecated
Only the Block marker interface in Phoenix (since marker interfaces were
declared bad). The notion of a Block as you describe still lives on in
Phoenix.
> 2) components are becoming blocks
Sure are!
> It's evident why we wan't find agreement on how to lookup components:
>
> lookup(role)
>
> returns a Block, while
>
> lookup(role, hint)
>
> returns a Component
Perhaps we need a BlockManager and ComponentManager interface to separate the
two?
interface BlockManager
{
Object lookup( String role );
}
interface ComponentManager
{
Object lookup( String role );
Object lookup( String role, Object hint );
}
> *THIS* is, IMO, the biggest design mistake done during my absence: you
> merged two different things into one, without understanding that they
> were totally different and they only thing they shared was
> avalon-lifecycle awareness.
The reasons for separation weren't recorded very visibly (if at all). Thus
the welcomed return of the "project elders" :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Paulo Gaspar <pa...@krankikom.de>.
Stefano,
All these ideas sound great and clear, but if you want to make such
concepts last we can not simply rely on posting them on a mailing
list. You have to post them in a more visible place.
There should be a document with this kind of info on Avalon's site,
and it should be very easy to find.
Where is it?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, June 21, 2002 1:41 AM
> To: Avalon Developers List
> Subject: Re: [desperate plea] RE: The need for 'hints'
>
>
> Leo Sutic wrote:
> >
> > > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > >
> > > Anyway, I'm changing my -1 to the removal of
> > > lookup(role,hint) to a +0 not to interfere with A5.
> >
> > Replacing your -1 with mine.
> >
> > > As for Berin's proposal, I think that the use cases you
> > > outlined, not all of them belong to Avalon.
> >
> > Container portability is good and all, but it forces the
> > concept of what a component is to become much narrower.
>
> I'll tell you the whole truth: the very first Avalon design didn't have
> components at all.
>
> Shoking my town :)
>
> Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
> bricks. Where polymorphic objects.
>
> Blocks had version, metadata dependencies, they were thread-safe, they
> were big.
>
> I remember a pretty heated discussion with Peter about the size of
> blocks. That time I even managed to change his mind ;-)
>
> Components were introduced later and were introduced mostly because the
> block patterns could be used inside the blocks as well, but where
> portability was not an issue anymore.
>
> So, we had the big reusable/sharable pieces called Blocks and the small
> pieces called Components.
>
> In short, Components were classes++, classes that followed the Avalon
> model. Since in java you want to the ability to instantiate a particular
> class, the need for hints emerged for Components (never for blocks!).
> Result: ComponentSelector.
>
> At that point I left this community for personal reasons.
>
> I come back a while after and:
>
> 1) blocks are deprecated
> 2) components are becoming blocks
> 3) direct component instantiation is considered harmful
>
> Without even noticing, the pure-COP promoters are going backwards: we
> were there already, you simply changed the name of 'block' to
> 'component'.
>
> > In Cocoon, a component can be something very small,
> > and in A5, a component will be something quite big.
>
> Gosh, things would be easier if you didn't deprecate the concept of
> 'block' and wanted to use the same name for two different things.
>
> block -> an avalon-lifecycle-aware polymorphic object, versionned,
> fully reentrant, sharable, not directly referentiable
>
> component -> an avalon-lifecycle-aware polymorphic object, directly
> referentiable
>
> It's evident why we wan't find agreement on how to lookup components:
>
> lookup(role)
>
> returns a Block, while
>
> lookup(role, hint)
>
> returns a Component.
>
> Cocoon, being itself block-like, references components. This is why it
> needs the ability to reference them directly.
>
> Phoenix/Merlin, on the other hand, being block containers, don't like
> hints because blocks are not directly referentiable (nor they should
> be!)
>
> *THIS* is, IMO, the biggest design mistake done during my absence: you
> merged two different things into one, without understanding that they
> were totally different and they only thing they shared was
> avalon-lifecycle awareness.
>
> > I'm not sure if I like that change. Much of what used
> > to be "applications using the Avalon framework" are now
> > so small that they would be individual components.
> > Don't ignore the small people, please!
>
> I agree. We should not.
>
> > Don't let Avalon
> > become something that is a heavyweight "for big jobs
> > only" framework. I'm sure there's a need for being able
> > to put small stuff into a container and have it pooled /
> > managed. That was the beauty of A4.
>
> > I'm sure we can find something that allows Avalon to scale
> > from small to big stuff.
>
> Hopefully the above will bring context.
>
> > As for the argument of use and abuse of Avalon, if someone
> > can take this framework, and produce a usable product with
> > it, how can we call that "abuse"?
>
> No, careful. Cocoon is block-like and required special treatment of
> internal components. That pushed more and more pressure on the handling
> on 'components' (using the terminology above, not the current avalon
> one) that twisted the clean design of Avalon.
>
> Removing the 'block' pillar forced too much pressure on the current
> concept of Component, leading to 'abuse' of patterns and the creation of
> inelegant solutions (like ComponentSelector, for example, which nobody
> ever liked but it was approved for need)
>
> > The way it is used in
> > Cocoon may not be what we consider proper and beautiful,
> > but it remains a fact that people have found Avalon to be
> > very useful that way.
>
> Yes, there is definately the need for two different kinds of polymorphic
> composition: direct and indirect. Direct is for small things that are
> not sharable nor interoperable, most of the time, application-specific,
> indirect is for bigger things, sharable, interoperable and fully
> reentrant.
>
> > Coming and saying "abuse! That's not
> > how we want you to use our framework" has quite a high
> > piss-off factor, migration path or not.
>
> Unless you clearly show why.
>
> > > I call for a restate of the Avalon's project charter!
> >
> > OK, so what do you propose we change it to?
>
> "restate" in my vocabulary means: 'state again'.
>
> I did in my previous email :)
>
> Hope this helps giving more context.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [desperate plea] RE: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Anyway, I'm changing my -1 to the removal of
> > lookup(role,hint) to a +0 not to interfere with A5.
>
> Replacing your -1 with mine.
>
> > As for Berin's proposal, I think that the use cases you
> > outlined, not all of them belong to Avalon.
>
> Container portability is good and all, but it forces the
> concept of what a component is to become much narrower.
I'll tell you the whole truth: the very first Avalon design didn't have
components at all.
Shoking my town :)
Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
bricks. Where polymorphic objects.
Blocks had version, metadata dependencies, they were thread-safe, they
were big.
I remember a pretty heated discussion with Peter about the size of
blocks. That time I even managed to change his mind ;-)
Components were introduced later and were introduced mostly because the
block patterns could be used inside the blocks as well, but where
portability was not an issue anymore.
So, we had the big reusable/sharable pieces called Blocks and the small
pieces called Components.
In short, Components were classes++, classes that followed the Avalon
model. Since in java you want to the ability to instantiate a particular
class, the need for hints emerged for Components (never for blocks!).
Result: ComponentSelector.
At that point I left this community for personal reasons.
I come back a while after and:
1) blocks are deprecated
2) components are becoming blocks
3) direct component instantiation is considered harmful
Without even noticing, the pure-COP promoters are going backwards: we
were there already, you simply changed the name of 'block' to
'component'.
> In Cocoon, a component can be something very small,
> and in A5, a component will be something quite big.
Gosh, things would be easier if you didn't deprecate the concept of
'block' and wanted to use the same name for two different things.
block -> an avalon-lifecycle-aware polymorphic object, versionned,
fully reentrant, sharable, not directly referentiable
component -> an avalon-lifecycle-aware polymorphic object, directly
referentiable
It's evident why we wan't find agreement on how to lookup components:
lookup(role)
returns a Block, while
lookup(role, hint)
returns a Component.
Cocoon, being itself block-like, references components. This is why it
needs the ability to reference them directly.
Phoenix/Merlin, on the other hand, being block containers, don't like
hints because blocks are not directly referentiable (nor they should
be!)
*THIS* is, IMO, the biggest design mistake done during my absence: you
merged two different things into one, without understanding that they
were totally different and they only thing they shared was
avalon-lifecycle awareness.
> I'm not sure if I like that change. Much of what used
> to be "applications using the Avalon framework" are now
> so small that they would be individual components.
> Don't ignore the small people, please!
I agree. We should not.
> Don't let Avalon
> become something that is a heavyweight "for big jobs
> only" framework. I'm sure there's a need for being able
> to put small stuff into a container and have it pooled /
> managed. That was the beauty of A4.
> I'm sure we can find something that allows Avalon to scale
> from small to big stuff.
Hopefully the above will bring context.
> As for the argument of use and abuse of Avalon, if someone
> can take this framework, and produce a usable product with
> it, how can we call that "abuse"?
No, careful. Cocoon is block-like and required special treatment of
internal components. That pushed more and more pressure on the handling
on 'components' (using the terminology above, not the current avalon
one) that twisted the clean design of Avalon.
Removing the 'block' pillar forced too much pressure on the current
concept of Component, leading to 'abuse' of patterns and the creation of
inelegant solutions (like ComponentSelector, for example, which nobody
ever liked but it was approved for need)
> The way it is used in
> Cocoon may not be what we consider proper and beautiful,
> but it remains a fact that people have found Avalon to be
> very useful that way.
Yes, there is definately the need for two different kinds of polymorphic
composition: direct and indirect. Direct is for small things that are
not sharable nor interoperable, most of the time, application-specific,
indirect is for bigger things, sharable, interoperable and fully
reentrant.
> Coming and saying "abuse! That's not
> how we want you to use our framework" has quite a high
> piss-off factor, migration path or not.
Unless you clearly show why.
> > I call for a restate of the Avalon's project charter!
>
> OK, so what do you propose we change it to?
"restate" in my vocabulary means: 'state again'.
I did in my previous email :)
Hope this helps giving more context.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [desperate plea] RE: The need for 'hints'
Posted by Paulo Gaspar <pa...@krankikom.de>.
I agree.
Avalon should be as "abusable" as possible.
One can always have a strict layer and an abusable one, or
can we not? Each project would use the most convenient one.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, June 20, 2002 11:14 AM
> To: 'Avalon Developers List'
> Subject: [desperate plea] RE: The need for 'hints'
>
>
>
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > Anyway, I'm changing my -1 to the removal of
> > lookup(role,hint) to a +0 not to interfere with A5.
>
> Replacing your -1 with mine.
>
> > As for Berin's proposal, I think that the use cases you
> > outlined, not all of them belong to Avalon.
>
> Container portability is good and all, but it forces the
> concept of what a component is to become much narrower.
> In Cocoon, a component can be something very small,
> and in A5, a component will be something quite big.
>
> I'm not sure if I like that change. Much of what used
> to be "applications using the Avalon framework" are now
> so small that they would be individual components.
> Don't ignore the small people, please! Don't let Avalon
> become something that is a heavyweight "for big jobs
> only" framework. I'm sure there's a need for being able
> to put small stuff into a container and have it pooled /
> managed. That was the beauty of A4.
>
> I'm sure we can find something that allows Avalon to scale
> from small to big stuff.
>
> As for the argument of use and abuse of Avalon, if someone
> can take this framework, and produce a usable product with
> it, how can we call that "abuse"? The way it is used in
> Cocoon may not be what we consider proper and beautiful,
> but it remains a fact that people have found Avalon to be
> very useful that way. Coming and saying "abuse! That's not
> how we want you to use our framework" has quite a high
> piss-off factor, migration path or not.
>
> > I call for a restate of the Avalon's project charter!
>
> OK, so what do you propose we change it to?
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[desperate plea] RE: The need for 'hints'
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Anyway, I'm changing my -1 to the removal of
> lookup(role,hint) to a +0 not to interfere with A5.
Replacing your -1 with mine.
> As for Berin's proposal, I think that the use cases you
> outlined, not all of them belong to Avalon.
Container portability is good and all, but it forces the
concept of what a component is to become much narrower.
In Cocoon, a component can be something very small,
and in A5, a component will be something quite big.
I'm not sure if I like that change. Much of what used
to be "applications using the Avalon framework" are now
so small that they would be individual components.
Don't ignore the small people, please! Don't let Avalon
become something that is a heavyweight "for big jobs
only" framework. I'm sure there's a need for being able
to put small stuff into a container and have it pooled /
managed. That was the beauty of A4.
I'm sure we can find something that allows Avalon to scale
from small to big stuff.
As for the argument of use and abuse of Avalon, if someone
can take this framework, and produce a usable product with
it, how can we call that "abuse"? The way it is used in
Cocoon may not be what we consider proper and beautiful,
but it remains a fact that people have found Avalon to be
very useful that way. Coming and saying "abuse! That's not
how we want you to use our framework" has quite a high
piss-off factor, migration path or not.
> I call for a restate of the Avalon's project charter!
OK, so what do you propose we change it to?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Leo Simons <le...@apache.org>.
> > Let me rephrase the question to "what do I gain from the seperation of
> > concerns of assembly for application context" and the answer to that is
> > portability of components across containers.
>
> Bingo, I think we touched the nerve: all Cocoon components where forced
> to be Avalon components, even those who cannot (nor should not) be
> portable across containers.
>
> That's admittedly a design mistake. We have been abusing Avalon since we
> used it too much, even where it would have made more sense to do our own
> stuff.
it probably makes a lot of sense (as Steve's pointing out in another
thread) to have these inherently non-portable components inside an
avalon-style container still, maybe extending something like fortress to
add support for stuff like this.
I dunno cocoon, so I can't say.
> I call for a restate of the Avalon's project charter!
???
> Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
> components which lookup mechanism's control cannot be completely
> inverted.
>
> Anybody against this?
Just the notion "Avalon 5". Should perhaps not be using *the proposed
standard Avalon 5 ComponentManager/Locator interface* for those
components.
cheers,
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
> components which lookup mechanism's control cannot be completely
> inverted.
What do you mean by "be using Avalon 5"?
Do you mean framework, excaliber stuff, or what?
What you say is conceptually clean, but in practice?
Please give me some examples :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Stephen McConnell wrote:
> Avalon Container Avalon Client
> Architecture Architecture
>
> |----------------| |----------------| |----------------|
> | integrity |<--->| knowledge |<--->| simplicity |
> | reuse | | practices | | usability |
> | portability | | context | | efficiency |
> | security | | | | consistency |
> | scalability | | | | |
> | reliability | | | | |
> |----------------| |----------------| |----------------|
>
>
You forgot to mention motherhood, apple pie, loyalty, minimizing
keysrokes, and fairness to our brothers. (Nice swordplay, huh?)
Integrity, security, scalability and reliability, efficiency and
consistency are attributes of good programming. It is not that Avalon is
not about these things because, Avalon is about good programming sure.
But does that mean that everything that is good programming must be
implemented within Avalon?
The objective of Avalon is COP or loose coupling or re-use or
portability or whatever term you want to use for it. Same basic idea,
different terminology.
Everything else is just good programming. VERY important yes, but not
the domain of Avalon. I can f*** up any of these magnificently, using
Avalon or not. As soon as you make Avalon complex just to effect a
police action against some idea of bad programming which is extraneous
to COP, then you are on the slippery slope to goofiness and sillyness.
Not bad, just extraneous. If, on the other hand, you can have it and
keep Avalon straightforward, then you are golden. But simplicity must be
deciding factor on whether or not it stays or goes.
Do one thing. Do it well. KISS.
Another saying floating around:
There is no sure way to success, but there is one guaranteed way to
fail, which is trying to be all things to all people.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stephen McConnell <mc...@osm.net>.
Stefano Mazzocchi wrote:
>
>Of course, the best thing would be for A5 to resurrect the separation
>between 'blocks' and 'components' as I stated previously. That would
>solve all problems
>
Lets take it just a tiny little step further because I happen to have
been working on just the subject (let's call it a coincidence). Based
on a lot of emails it appears to me that there is a potential reference
point that "could" be shared by the majority (wow, I'm getting
adventurous - perhaps this isn't going to be such a little step after all):
A Policy Statement:
-------------------
1. restrictions over and above the "freedom" and "liberty" that user's
have grown to love and respect shall not be retracted
[i.e. words such as "freedom", "liberty" and "abuse" all reflect a
differential between the informal and formal models of usage.
That differential has been established and cannot be resided.]
2. recognizing that, there is potential for restructuring, adaptation and
migration on a premise of "more gain than pain"
[i.e. we all want to move forward and it is recognized that this
may involve changes in practices, approaches, and ownership over time
but the common denominator is the existence of a mutual value
proposition]
3. whilst recognizing and respecting the overriding precept of a
framework grounded on the mandate of delivering, maintaining and
evolving a component framework supporting development, deployment,
execution and reuse.
[i.e. that within core of Avalon there are some things that are
sacred, things that touch at the very integrity of the platform,
and these things must not be compromised]
The above policy statement was prepared with a reasonable degree of care
in the selection of words, the implications therein and the emphasis
assigned. There is a clearly identified and healthy conflict of
interest between point (1) and (3) and the context and rules of
collaboration identified under point (2). Why put this into words - to
capture the value around the table. Because the next phase in Avalon
evolution involves solutions that will capture and engage (1) through
engineering solutions from (3) via active and engage activity in (2).
A Strategy Statement:
---------------------
To get the point of this whole thread - "the need for hints".
Isn't this a question of SOC?
Avalon Container Avalon Client
Architecture Architecture
|----------------| |----------------| |----------------|
| integrity |<--->| knowledge |<--->| simplicity |
| reuse | | practices | | usability |
| portability | | context | | efficiency |
| security | | | | consistency |
| scalability | | | | |
| reliability | | | | |
|----------------| |----------------| |----------------|
Providing there is framework for the introduction domain knowledge,
practices (good and bad) and application context between the
formal-component-container-abstraction and a less constrained client
abstraction, we have a management context with which to deliver a
spectrum of component management solutions that embrace a common and
sustainable architectural framework - a.k.a. the foward-looking strategy
for A4.2...A4.X, A5?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
> >Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
> >components which lookup mechanism's control cannot be completely
> >inverted.
> >
> >Anybody against this?
> >
> >
>
> What is the impact of the above?
Please, understand I can only state my perceptions, I can only speak as
a cocoon developer, but any other might have a different opinion.
If the next Avalon will not allow Cocoon to request the specific
implementation of a component explicitly, we'll implement such a system
ourselves (or stick with Avalon 4, depending on what the 'avalon market'
does).
> I'm assuming this concerns any
> component that is invoking lookup with a role argument that cannot
> reasonably be expressed as type information (i.e. dependecies, provided
> services, etc).
Exactly.
In theory, it could be possible to pass enough information to the lookup
system in order for it to come up with a transparent constraint crawl,
but given the way Cocoon is designed, it wouldn't work without *major*
changes in the conceptual model.
In fact, the above motion of 'hint-based' lookup gets up to the sitemap
<generate type="file" src="..."/>
uses 'file' as the hint. It's the equivalent of
generator = (Generator) GeneratorManager("file");
plus avalon-lifecycle awareness during creation and resource pooling.
> My impression is that this potentially represents
> something in the order of 20% of Cocoon components.
No, much more. Probably around 80/90%.
> I'm also assuming
> here that the migration path would be something along the lines of the
> componenet requesting a Cocon component repository (for example) and
> doing query based lookups from there. Am I on the right track here ?
Hmmm, it would make sense if we wanted those component repositories to
be reusable across other avalon implementations, but since this is not
our goal, why bother? Building up our own stuff and controlling it
in-house makes much more sense to me.
Of course, the best thing would be for A5 to resurrect the separation
between 'blocks' and 'components' as I stated previously. That would
solve all problems, but this is a conceptual detail I'm not even going
to try fighting.
So, if it happens, great, if not, at least I tried.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stephen McConnell <mc...@osm.net>.
Stefano Mazzocchi wrote:
>>Stefano:
>>
>>Image that you have to live with the rule that assembly infromation may
>>not be supplied to a container as a method argument. Imagine that this
>>is a really strinct rule - that is enforced by generic containers.
>>
>>
>
>Ok, let's assume that.
>
>
>
>> There are two conclusions you can draw from this:
>>1. that it is a components responsibility to publish assembly criteria
>>and functional constraints formally
>>2. that criteria that connot be expressed at a type level (i.e. in meta
>>declarations) is criteria that is application specific in which case the
>>component should be requesting a component capabable of servicing the
>>application level semantics
>>
>>
>>
>>>then, what do I gain from A5?
>>>
>>>
>>>
>>Let me rephrase the question to "what do I gain from the seperation of
>>concerns of assembly for application context" and the answer to that is
>>portability of components across containers.
>>
>>
>
>Bingo, I think we touched the nerve: all Cocoon components where forced
>to be Avalon components, even those who cannot (nor should not) be
>portable across containers.
>
>That's admittedly a design mistake. We have been abusing Avalon since we
>used it too much, even where it would have made more sense to do our own
>stuff.
>
>
>
>>>Ok, great. So, what's wrong with
>>>
>>>lookup(role, policy)
>>>
>>>?
>>>
>>>
>>The most significant thing that is wrong about this is that it places
>>infromation about assembly into the code of the component. Keep in mind
>>that the lookup operation is only concerned about assembly. As soon as
>>something goes into the lookup operation that is not opaque and managed
>>within the componet namespace, your eliminating the potential for
>>validation and assembly tools that are dependent on the expression of
>>this information at a type level. For example, I can assemble a
>>component type graph without instantiating a single component. I can
>>validate that assembly without instantiating a single component. But if
>>you put structure into the role argument, or if you supply a policy
>>argument, your introducing criteria that must be really formall defined
>>(so that generic containers can undersand it in an interoperable
>>fashion), and you eliminating the potential for pre-instantiation
>>validation (i.e. deferring validation until the lookup request hits the
>>component manager).
>>
>>
>
>Yes, I feel I beging to see your point and Peter's as well: if the goal
>is to have avalon components safely portable across containers, we must
>complete the inversion of control and a 2-d lookup mechanism doesn't
>allow this to happen.
>
>This forces Cocoon *not* to use Avalon for certain things like its
>internal intrinsically container-tight components.
>
>
>
>>What sort of information do you want to supply via lookup ?
>>How does this information relate to existing component types and
>>instantiated component instances managed by the container?
>> From you answer I'll try to explain how this can work, and what the
>>implications are relative to the container and the component.
>>
>>
>
>No, no, with the light of 'easing portability of components' I agree
>that it makes no sense for us Cocooners to push in this direction
>because they are different concerns.
>
>I'm still worried about the fact that it will be harder to push in the
>direction of A5 if less functionality is provided to Cocoon than A4
>(which works well for us today) and more stuff will have to be rewritten
>by ourselves directly.
>
>I do see the need for it, since it's true: Cocoon uses Avalon to manage
>the lookup of both *real* Avalon components (those that should be
>portable) and for cocoon components (that should *not* be portable
>because it wouldn't make any sense to try to do so)
>
>
>
>>Its puts assembly semantics into code and that eliminates the potential
>>for validation before execution. Elimination of this step eliminates
>>the potential for real management (i.e. suite type management).
>>
>>
>
>I think the catch-22 issue comes from the fact that Cocoon used Avalon
>too much, even where it didn't make sense. You guys now want to refactor
>it and clean its mistakes and I agree that Cocoon should not force bad
>design decisions because of past abuse.
>
>At the same time, the inertia of Cocoon is *very* big now and with
>several books coming out, it's hard to change things so deeply without
>pissing everybody off.
>
>Anyway, I'm changing my -1 to the removal of lookup(role,hint) to a +0
>not to interfere with A5.
>
>As for Berin's proposal, I think that the use cases you outlined, not
>all of them belong to Avalon.
>
>I call for a restate of the Avalon's project charter!
>
>
>
>>>
>>>
>>>>The key points are;
>>>>
>>>>* separating the lookup key for dependency from set of constraints
>>>>associated with dependency
>>>>
>>>>
>>>>
>>>>
>>>Absolutely, I agree they should be decoupled, this is exactly why I
>>>liked the 2-d lookup approach where one dimension connected with the
>>>dependency and another one to the constraints associated with the
>>>dependency.
>>>
>>>
>>>
>>But its in the code!!
>>This information does not need respide in the code.
>>This information can be used in a maner which is orthogonal to the
>>component.
>>This information is part of the structural contract and must be declared
>>in order for delivery of components.
>>
>>
>
>Unfortunately, there are cases (Cocoon is one of them) where this clear
>separation is not possible.
>
>But I do agree that the fact that Cocoon should use Avalon even in those
>cases where this is not possible was an arbitrary decision.
>
>
>
>>>>* simplifying interface from user perspective and making it harder to abuse
>>>>the
>>>>* separating out separate stages/views (ie assembler vs develoepr view).
>>>>* easing product evolution
>>>>
>>>>
>>>>
>>>>
>>>These are highly subjective and I won't question them.
>>>
>>>Like I said, I like what I see, but I fail to see why a 2-d lookup space
>>>is a bad thing, even with the context you give me.
>>>
>>>
>>>
>>>
>>Because its in the code - its in the code - its in the code!
>>
>>
>
>:)
>
>Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
>components which lookup mechanism's control cannot be completely
>inverted.
>
>Anybody against this?
>
>
What is the impact of the above? I'm assuming this concerns any
component that is invoking lookup with a role argument that cannot
reasonably be expressed as type information (i.e. dependecies, provided
services, etc). My impression is that this potentially represents
something in the order of 20% of Cocoon components. I'm also assuming
here that the migration path would be something along the lines of the
componenet requesting a Cocon component repository (for example) and
doing query based lookups from there. Am I on the right track here ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Stefano brings up what seems to be my biggest question:
*What is Avalon for?*
If the answer is anything other than pluggability or portability of
components, this needs to be clarified.
<flamebait>
Loose coupling is the only reason I am here. For everything else,
straight OO is dumber, easier, more direct.
</flamebait>
If this is the case, then the first thing that needs to be shown on the
Avalon page is not explanation of IoC and SoC but instead when to use
Avalon and when not to.
This would also cut down on a lot of the back and forth, as it appears
that the heart of the differences is not in how to do things, but what
is trying to be done. If we don't agree on what we are trying to do,
then how to do it can be argued until the cows come home.
<regarding Cocoon only>
Having Cocoon stuck with Avalon 4 seems like a non-problem, as Avalon 4
is a miles ahead of straight OO which would be the alternative. So, what
is the problem if Avalon moves ahead and Cocoon sticks at 4 for a year
or two, if a migration tool really wouldn't do the trick?
</regarding Cocoon only>
Nothing below but snips of Stefano's comments:
Stefano Mazzocchi wrote: <snipped all up, without snips showing>
>Bingo, I think we touched the nerve: all Cocoon components where forced
>to be Avalon components, even those who cannot (nor should not) be
>portable across containers.
>
>That's admittedly a design mistake. We have been abusing Avalon since we
>used it too much, even where it would have made more sense to do our own
>stuff.
>
>
>Yes, I feel I beging to see your point and Peter's as well: if the goal
>is to have avalon components safely portable across containers, we must
>complete the inversion of control and a 2-d lookup mechanism doesn't
>allow this to happen.
>
>This forces Cocoon *not* to use Avalon for certain things like its
>internal intrinsically container-tight components.
>
>
>No, no, with the light of 'easing portability of components' I agree
>that it makes no sense for us Cocooners to push in this direction
>because they are different concerns.
>
>I'm still worried about the fact that it will be harder to push in the
>direction of A5 if less functionality is provided to Cocoon than A4
>(which works well for us today) and more stuff will have to be rewritten
>by ourselves directly.
>
>I do see the need for it, since it's true: Cocoon uses Avalon to manage
>the lookup of both *real* Avalon components (those that should be
>portable) and for cocoon components (that should *not* be portable
>because it wouldn't make any sense to try to do so)
>
>
>I think the catch-22 issue comes from the fact that Cocoon used Avalon
>too much, even where it didn't make sense. You guys now want to refactor
>it and clean its mistakes and I agree that Cocoon should not force bad
>design decisions because of past abuse.
>
>At the same time, the inertia of Cocoon is *very* big now and with
>several books coming out, it's hard to change things so deeply without
>pissing everybody off.
>
>I call for a restate of the Avalon's project charter!
>
>Unfortunately, there are cases (Cocoon is one of them) where this clear
>separation is not possible.
>
>But I do agree that the fact that Cocoon should use Avalon even in those
>cases where this is not possible was an arbitrary decision.
>
>
>Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
>components which lookup mechanism's control cannot be completely
>inverted.
>
>Anybody against this?
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
> Stefano:
>
> Image that you have to live with the rule that assembly infromation may
> not be supplied to a container as a method argument. Imagine that this
> is a really strinct rule - that is enforced by generic containers.
Ok, let's assume that.
> There are two conclusions you can draw from this:
> 1. that it is a components responsibility to publish assembly criteria
> and functional constraints formally
> 2. that criteria that connot be expressed at a type level (i.e. in meta
> declarations) is criteria that is application specific in which case the
> component should be requesting a component capabable of servicing the
> application level semantics
>
> >
> >then, what do I gain from A5?
> >
>
> Let me rephrase the question to "what do I gain from the seperation of
> concerns of assembly for application context" and the answer to that is
> portability of components across containers.
Bingo, I think we touched the nerve: all Cocoon components where forced
to be Avalon components, even those who cannot (nor should not) be
portable across containers.
That's admittedly a design mistake. We have been abusing Avalon since we
used it too much, even where it would have made more sense to do our own
stuff.
> >Ok, great. So, what's wrong with
> >
> > lookup(role, policy)
> >
> >?
>
> The most significant thing that is wrong about this is that it places
> infromation about assembly into the code of the component. Keep in mind
> that the lookup operation is only concerned about assembly. As soon as
> something goes into the lookup operation that is not opaque and managed
> within the componet namespace, your eliminating the potential for
> validation and assembly tools that are dependent on the expression of
> this information at a type level. For example, I can assemble a
> component type graph without instantiating a single component. I can
> validate that assembly without instantiating a single component. But if
> you put structure into the role argument, or if you supply a policy
> argument, your introducing criteria that must be really formall defined
> (so that generic containers can undersand it in an interoperable
> fashion), and you eliminating the potential for pre-instantiation
> validation (i.e. deferring validation until the lookup request hits the
> component manager).
Yes, I feel I beging to see your point and Peter's as well: if the goal
is to have avalon components safely portable across containers, we must
complete the inversion of control and a 2-d lookup mechanism doesn't
allow this to happen.
This forces Cocoon *not* to use Avalon for certain things like its
internal intrinsically container-tight components.
> What sort of information do you want to supply via lookup ?
> How does this information relate to existing component types and
> instantiated component instances managed by the container?
> From you answer I'll try to explain how this can work, and what the
> implications are relative to the container and the component.
No, no, with the light of 'easing portability of components' I agree
that it makes no sense for us Cocooners to push in this direction
because they are different concerns.
I'm still worried about the fact that it will be harder to push in the
direction of A5 if less functionality is provided to Cocoon than A4
(which works well for us today) and more stuff will have to be rewritten
by ourselves directly.
I do see the need for it, since it's true: Cocoon uses Avalon to manage
the lookup of both *real* Avalon components (those that should be
portable) and for cocoon components (that should *not* be portable
because it wouldn't make any sense to try to do so)
> Its puts assembly semantics into code and that eliminates the potential
> for validation before execution. Elimination of this step eliminates
> the potential for real management (i.e. suite type management).
I think the catch-22 issue comes from the fact that Cocoon used Avalon
too much, even where it didn't make sense. You guys now want to refactor
it and clean its mistakes and I agree that Cocoon should not force bad
design decisions because of past abuse.
At the same time, the inertia of Cocoon is *very* big now and with
several books coming out, it's hard to change things so deeply without
pissing everybody off.
Anyway, I'm changing my -1 to the removal of lookup(role,hint) to a +0
not to interfere with A5.
As for Berin's proposal, I think that the use cases you outlined, not
all of them belong to Avalon.
I call for a restate of the Avalon's project charter!
> >
> >
> >>The key points are;
> >>
> >>* separating the lookup key for dependency from set of constraints
> >>associated with dependency
> >>
> >>
> >
> >Absolutely, I agree they should be decoupled, this is exactly why I
> >liked the 2-d lookup approach where one dimension connected with the
> >dependency and another one to the constraints associated with the
> >dependency.
> >
>
> But its in the code!!
> This information does not need respide in the code.
> This information can be used in a maner which is orthogonal to the
> component.
> This information is part of the structural contract and must be declared
> in order for delivery of components.
Unfortunately, there are cases (Cocoon is one of them) where this clear
separation is not possible.
But I do agree that the fact that Cocoon should use Avalon even in those
cases where this is not possible was an arbitrary decision.
> >>* simplifying interface from user perspective and making it harder to abuse
> >>the
> >>* separating out separate stages/views (ie assembler vs develoepr view).
> >>* easing product evolution
> >>
> >>
> >
> >These are highly subjective and I won't question them.
> >
> >Like I said, I like what I see, but I fail to see why a 2-d lookup space
> >is a bad thing, even with the context you give me.
> >
> >
>
> Because its in the code - its in the code - its in the code!
:)
Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
components which lookup mechanism's control cannot be completely
inverted.
Anybody against this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stephen McConnell <mc...@osm.net>.
Stefano Mazzocchi wrote:
>Peter Donald wrote:
>
>
>>At 08:15 PM 6/17/2002 +0200, you wrote:
>>
>>
>>>>The role name is just that - an arbitrary name. ie Stephen tends to use
>>>>names such as "socket-factory", "ssl-socket-factory" etc which are quite
>>>>valid (even if I dislike that they no follow defacto standard). Each role
>>>>name designates a component that satisfies certain constraints. In
>>>>ECM/Cocoon land there is only one constraint (ie class/type of returned
>>>>component) hence the rolename maps to class returned. In some containers
>>>>there can be other constraints.
>>>>
>>>>
>>>Ok, this is probably a context that I'm misssing, can you elaborate more
>>>on this? It would be helpful to understand your insights.
>>>
>>>
>>Okay I will try ;)
>>
>>
>
>Thanks, this makes it a lot clearer. Please, see my comments intermixed.
>
>
>
>>Perhaps it is better to describe it in terms of a hypothetical container
>>that could be created once I finish the new metainfo stuff. Consider a
>>component X. Associated with that component is some metainfo and assuming
>>it is a similar format to Phoenixs Blockinfo assume it has a section such as
>>
>><component>
>>...
>> <dependencies>
>> <dependency>
>> <role>my-transformer</role>
>> <service classname="org.apache.cocoon.api.Transformer"/>
>> <attribute name="type" value="xslt"/>
>> </dependency>
>> </dependencies>
>>...
>></component>
>>
>>This saids that X has a dependency on a component that implements interface
>>org.apache.cocoon.api.Transformer, is of type "xslt" and is accessed from
>>ComponentManager using the key "my-transformer". Note I have intentionally
>>left "type=xslt" undefined as it is a container specific concept.
>>(Alternatively you may do something like "handles-dtd=..." or whatever).
>>
>><service/> + <attribute/>s == constraints on dependency
>><role/> == key used to lookup component
>>
>>So all the container needs to do is lookup a component with the key
>>"my-transformer" and the correct component is returned.
>>
>>
>
>Cocoon needs a 2-d lookup space, this is not going to change in the
>future. The above doesn't give it to me unless I namespace the key:
>
> - 'generator:file'
> - 'org.apache.cocoon.generating.Generator/file'
> - ???
>
Stefano:
Image that you have to live with the rule that assembly infromation may
not be supplied to a container as a method argument. Imagine that this
is a really strinct rule - that is enforced by generic containers.
There are two conclusions you can draw from this:
1. that it is a components responsibility to publish assembly criteria
and functional constraints formally
2. that criteria that connot be expressed at a type level (i.e. in meta
declarations) is criteria that is application specific in which case the
component should be requesting a component capabable of servicing the
application level semantics
>
>then, what do I gain from A5?
>
Let me rephrase the question to "what do I gain from the seperation of
concerns of assembly for application context" and the answer to that is
portability of components across containers.
>
>
>
>>The process of determining the correct component is essentially what we
>>have been terming "assembly" and is currently container specific (and will
>>continue to be so in all likelihood).
>>
>>
>
>Of course.
>
>
>
>>* Phoenix requires that the user explicitly assemble component and make
>>sure all components have their components mapped correctly etc.
>>
>>
>
>Ok.
>
>
>
>>* Merlin will auotmatically assemble the application. ie For each
>>dependency it will look for potential providers among other components. If
>>there is only one potential provider it will use that. If there is more
>>than one potential provider then it will select one based on some heuristic
>>(it uses a "policy" (aka "hint") attribute).
>>
>>
>
>Ok, great. So, what's wrong with
>
> lookup(role, policy)
>
>?
>
>
The most significant thing that is wrong about this is that it places
infromation about assembly into the code of the component. Keep in mind
that the lookup operation is only concerned about assembly. As soon as
something goes into the lookup operation that is not opaque and managed
within the componet namespace, your eliminating the potential for
validation and assembly tools that are dependent on the expression of
this information at a type level. For example, I can assemble a
component type graph without instantiating a single component. I can
validate that assembly without instantiating a single component. But if
you put structure into the role argument, or if you supply a policy
argument, your introducing criteria that must be really formall defined
(so that generic containers can undersand it in an interoperable
fashion), and you eliminating the potential for pre-instantiation
validation (i.e. deferring validation until the lookup request hits the
component manager).
>
>
>>* ECM does not separate out assembly and development stages. Effectively
>>you hardwire the assembly information into the components when you supply
>>interface name + "hint"
>>
>>
>
>This is the hack I'm referring to when I see ROLE + "/hint" and I
>totally agree with you that this is bad.
>
>*STILL* I need a way to suggest the container a specific lookup policy
>(strategy, methodology, philosophy, call it as you like! but we *NEED*
>that information separate from the role)
>
>Look: because Phoenix doesn't need it, it doesn't mean that the rest of
>the world doesn't need it.
>
>Moreover, you are explicitly stating that other containers (Merlin) need
>that, so what's the damn problem with a 2-d lookup mechanism?
>
>
If a think called a lookup policy comes in through a lookup operation,
what should Merlin do with this ?
How would it effect Merlin's composition strategy ?
>
>
>>* Fortress is currently similar to ECM but Leo plans to fix it so that it
>>is possible to to assemble component outside code (whether he chooses
>>Merlin or Fortresses strategy I am not sure but I believe Merlins is more
>>approriate for Cocoon).
>>
>>So if Leo chooses to go the Merlin-esque route then there will no changes
>>to current sitemap format unless you want to explicitly declare a mapping
>>rather than allowing the container to auotmatically manage it.
>>
>>What will be changed is the presence of per component descriptors. You may
>>say that these are a PITA to maintain (and they are!) so what I plan to do
>>is create an XDoclet task to autogenerate them.
>>
>>
>
>hmmm,
>
>
>
>>So what you will need to do
>>is add in javadoc markup to your component so that they look like the
>>following.
>>
>>/**
>> * @avalon.component lifestyle="threadsafe"
>> */
>>class MyComponent
>>{
>> /**
>> * @avalon.dependency role="my-transformer" service="Transformer"
>>type="xslt"
>> */
>> void compose(ComponentManager cm)
>> {
>> m_myDependency = (Transformer)cm.lookup( "my-transformer" );
>> }
>>}
>>
>>Note the above would produce a descriptorsimilar to the one I outlined
>>above. However in cases where you follow the convention and the lookup key
>>is the same as the interface name you can get away with even less markup so
>>that it just looks like
>>
>> /**
>> * @avalon.dependency service="Transformer" type="xslt"
>> */
>> void compose(ComponentManager cm)
>> {
>> m_myDependency = (Transformer)cm.lookup( Transformer.ROLE );
>> }
>>
>>An architecture like the above is soooooo much easier to maintain than the
>>current ECM which has a global namespace and treats the ComponentManager as
>>a Container. It will also allow much more flexability in future and is more
>>maintainable.
>>
>>
>
>Know what? I tend to agree with this. The need for all those
>class="org.apache.*" stuff in XML files bothered me a lot. Placing them
>in a XDoclet type wrapper makes a lot of sense, even if it won't be easy
>to make the cocoon-dev community buy that.
>
>
>
>>Given an architecture like this there is no longer any need for a second
>>hint parameter in ComponentManager.lookup() method.
>>
>>
>
>But I can't see this. Sorry, please, be patient.
>
What sort of information do you want to supply via lookup ?
How does this information relate to existing component types and
instantiated component instances managed by the container?
From you answer I'll try to explain how this can work, and what the
implications are relative to the container and the component.
>
>
>
>>It would also allow all
>>the containers to share components which is currently not possible due to
>>differences in way we specify metadata.
>>
>>Does that make it any clearer?
>>
>>
>
>Yes, I like what I see conceptually, but I don't see, from what I
>understood, why you feel that a 2-d lookup space (role,policy) is bad.
>
>
Its puts assembly semantics into code and that eliminates the potential
for validation before execution. Elimination of this step eliminates
the potential for real management (i.e. suite type management).
>
>
>>The key points are;
>>
>>* separating the lookup key for dependency from set of constraints
>>associated with dependency
>>
>>
>
>Absolutely, I agree they should be decoupled, this is exactly why I
>liked the 2-d lookup approach where one dimension connected with the
>dependency and another one to the constraints associated with the
>dependency.
>
But its in the code!!
This information does not need respide in the code.
This information can be used in a maner which is orthogonal to the
component.
This information is part of the structural contract and must be declared
in order for delivery of components.
>
>
>
>>* simplifying interface from user perspective and making it harder to abuse
>>the
>>* separating out separate stages/views (ie assembler vs develoepr view).
>>* easing product evolution
>>
>>
>
>These are highly subjective and I won't question them.
>
>Like I said, I like what I see, but I fail to see why a 2-d lookup space
>is a bad thing, even with the context you give me.
>
>
Because its in the code - its in the code - its in the code!
:-)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 08:15 PM 6/17/2002 +0200, you wrote:
> > > The role name is just that - an arbitrary name. ie Stephen tends to use
> > > names such as "socket-factory", "ssl-socket-factory" etc which are quite
> > > valid (even if I dislike that they no follow defacto standard). Each role
> > > name designates a component that satisfies certain constraints. In
> > > ECM/Cocoon land there is only one constraint (ie class/type of returned
> > > component) hence the rolename maps to class returned. In some containers
> > > there can be other constraints.
> >
> >Ok, this is probably a context that I'm misssing, can you elaborate more
> >on this? It would be helpful to understand your insights.
>
> Okay I will try ;)
Thanks, this makes it a lot clearer. Please, see my comments intermixed.
> Perhaps it is better to describe it in terms of a hypothetical container
> that could be created once I finish the new metainfo stuff. Consider a
> component X. Associated with that component is some metainfo and assuming
> it is a similar format to Phoenixs Blockinfo assume it has a section such as
>
> <component>
> ...
> <dependencies>
> <dependency>
> <role>my-transformer</role>
> <service classname="org.apache.cocoon.api.Transformer"/>
> <attribute name="type" value="xslt"/>
> </dependency>
> </dependencies>
> ...
> </component>
>
> This saids that X has a dependency on a component that implements interface
> org.apache.cocoon.api.Transformer, is of type "xslt" and is accessed from
> ComponentManager using the key "my-transformer". Note I have intentionally
> left "type=xslt" undefined as it is a container specific concept.
> (Alternatively you may do something like "handles-dtd=..." or whatever).
>
> <service/> + <attribute/>s == constraints on dependency
> <role/> == key used to lookup component
>
> So all the container needs to do is lookup a component with the key
> "my-transformer" and the correct component is returned.
Cocoon needs a 2-d lookup space, this is not going to change in the
future. The above doesn't give it to me unless I namespace the key:
- 'generator:file'
- 'org.apache.cocoon.generating.Generator/file'
- ???
then, what do I gain from A5?
> The process of determining the correct component is essentially what we
> have been terming "assembly" and is currently container specific (and will
> continue to be so in all likelihood).
Of course.
> * Phoenix requires that the user explicitly assemble component and make
> sure all components have their components mapped correctly etc.
Ok.
> * Merlin will auotmatically assemble the application. ie For each
> dependency it will look for potential providers among other components. If
> there is only one potential provider it will use that. If there is more
> than one potential provider then it will select one based on some heuristic
> (it uses a "policy" (aka "hint") attribute).
Ok, great. So, what's wrong with
lookup(role, policy)
?
> * ECM does not separate out assembly and development stages. Effectively
> you hardwire the assembly information into the components when you supply
> interface name + "hint"
This is the hack I'm referring to when I see ROLE + "/hint" and I
totally agree with you that this is bad.
*STILL* I need a way to suggest the container a specific lookup policy
(strategy, methodology, philosophy, call it as you like! but we *NEED*
that information separate from the role)
Look: because Phoenix doesn't need it, it doesn't mean that the rest of
the world doesn't need it.
Moreover, you are explicitly stating that other containers (Merlin) need
that, so what's the damn problem with a 2-d lookup mechanism?
> * Fortress is currently similar to ECM but Leo plans to fix it so that it
> is possible to to assemble component outside code (whether he chooses
> Merlin or Fortresses strategy I am not sure but I believe Merlins is more
> approriate for Cocoon).
>
> So if Leo chooses to go the Merlin-esque route then there will no changes
> to current sitemap format unless you want to explicitly declare a mapping
> rather than allowing the container to auotmatically manage it.
>
> What will be changed is the presence of per component descriptors. You may
> say that these are a PITA to maintain (and they are!) so what I plan to do
> is create an XDoclet task to autogenerate them.
hmmm,
> So what you will need to do
> is add in javadoc markup to your component so that they look like the
> following.
>
> /**
> * @avalon.component lifestyle="threadsafe"
> */
> class MyComponent
> {
> /**
> * @avalon.dependency role="my-transformer" service="Transformer"
> type="xslt"
> */
> void compose(ComponentManager cm)
> {
> m_myDependency = (Transformer)cm.lookup( "my-transformer" );
> }
> }
>
> Note the above would produce a descriptorsimilar to the one I outlined
> above. However in cases where you follow the convention and the lookup key
> is the same as the interface name you can get away with even less markup so
> that it just looks like
>
> /**
> * @avalon.dependency service="Transformer" type="xslt"
> */
> void compose(ComponentManager cm)
> {
> m_myDependency = (Transformer)cm.lookup( Transformer.ROLE );
> }
>
> An architecture like the above is soooooo much easier to maintain than the
> current ECM which has a global namespace and treats the ComponentManager as
> a Container. It will also allow much more flexability in future and is more
> maintainable.
Know what? I tend to agree with this. The need for all those
class="org.apache.*" stuff in XML files bothered me a lot. Placing them
in a XDoclet type wrapper makes a lot of sense, even if it won't be easy
to make the cocoon-dev community buy that.
> Given an architecture like this there is no longer any need for a second
> hint parameter in ComponentManager.lookup() method.
But I can't see this. Sorry, please, be patient.
> It would also allow all
> the containers to share components which is currently not possible due to
> differences in way we specify metadata.
>
> Does that make it any clearer?
Yes, I like what I see conceptually, but I don't see, from what I
understood, why you feel that a 2-d lookup space (role,policy) is bad.
> The key points are;
>
> * separating the lookup key for dependency from set of constraints
> associated with dependency
Absolutely, I agree they should be decoupled, this is exactly why I
liked the 2-d lookup approach where one dimension connected with the
dependency and another one to the constraints associated with the
dependency.
> * simplifying interface from user perspective and making it harder to abuse
> the
> * separating out separate stages/views (ie assembler vs develoepr view).
> * easing product evolution
These are highly subjective and I won't question them.
Like I said, I like what I see, but I fail to see why a 2-d lookup space
is a bad thing, even with the context you give me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 08:15 PM 6/17/2002 +0200, you wrote:
> > The role name is just that - an arbitrary name. ie Stephen tends to use
> > names such as "socket-factory", "ssl-socket-factory" etc which are quite
> > valid (even if I dislike that they no follow defacto standard). Each role
> > name designates a component that satisfies certain constraints. In
> > ECM/Cocoon land there is only one constraint (ie class/type of returned
> > component) hence the rolename maps to class returned. In some containers
> > there can be other constraints.
>
>Ok, this is probably a context that I'm misssing, can you elaborate more
>on this? It would be helpful to understand your insights.
Okay I will try ;)
Perhaps it is better to describe it in terms of a hypothetical container
that could be created once I finish the new metainfo stuff. Consider a
component X. Associated with that component is some metainfo and assuming
it is a similar format to Phoenixs Blockinfo assume it has a section such as
<component>
...
<dependencies>
<dependency>
<role>my-transformer</role>
<service classname="org.apache.cocoon.api.Transformer"/>
<attribute name="type" value="xslt"/>
</dependency>
</dependencies>
...
</component>
This saids that X has a dependency on a component that implements interface
org.apache.cocoon.api.Transformer, is of type "xslt" and is accessed from
ComponentManager using the key "my-transformer". Note I have intentionally
left "type=xslt" undefined as it is a container specific concept.
(Alternatively you may do something like "handles-dtd=..." or whatever).
<service/> + <attribute/>s == constraints on dependency
<role/> == key used to lookup component
So all the container needs to do is lookup a component with the key
"my-transformer" and the correct component is returned.
The process of determining the correct component is essentially what we
have been terming "assembly" and is currently container specific (and will
continue to be so in all likelihood).
* Phoenix requires that the user explicitly assemble component and make
sure all components have their components mapped correctly etc.
* Merlin will auotmatically assemble the application. ie For each
dependency it will look for potential providers among other components. If
there is only one potential provider it will use that. If there is more
than one potential provider then it will select one based on some heuristic
(it uses a "policy" (aka "hint") attribute).
* ECM does not separate out assembly and development stages. Effectively
you hardwire the assembly information into the components when you supply
interface name + "hint"
* Fortress is currently similar to ECM but Leo plans to fix it so that it
is possible to to assemble component outside code (whether he chooses
Merlin or Fortresses strategy I am not sure but I believe Merlins is more
approriate for Cocoon).
So if Leo chooses to go the Merlin-esque route then there will no changes
to current sitemap format unless you want to explicitly declare a mapping
rather than allowing the container to auotmatically manage it.
What will be changed is the presence of per component descriptors. You may
say that these are a PITA to maintain (and they are!) so what I plan to do
is create an XDoclet task to autogenerate them. So what you will need to do
is add in javadoc markup to your component so that they look like the
following.
/**
* @avalon.component lifestyle="threadsafe"
*/
class MyComponent
{
/**
* @avalon.dependency role="my-transformer" service="Transformer"
type="xslt"
*/
void compose(ComponentManager cm)
{
m_myDependency = (Transformer)cm.lookup( "my-transformer" );
}
}
Note the above would produce a descriptorsimilar to the one I outlined
above. However in cases where you follow the convention and the lookup key
is the same as the interface name you can get away with even less markup so
that it just looks like
/**
* @avalon.dependency service="Transformer" type="xslt"
*/
void compose(ComponentManager cm)
{
m_myDependency = (Transformer)cm.lookup( Transformer.ROLE );
}
An architecture like the above is soooooo much easier to maintain than the
current ECM which has a global namespace and treats the ComponentManager as
a Container. It will also allow much more flexability in future and is more
maintainable.
Given an architecture like this there is no longer any need for a second
hint parameter in ComponentManager.lookup() method. It would also allow all
the containers to share components which is currently not possible due to
differences in way we specify metadata.
Does that make it any clearer?
The key points are;
* separating the lookup key for dependency from set of constraints
associated with dependency
* simplifying interface from user perspective and making it harder to abuse
the
* separating out separate stages/views (ie assembler vs develoepr view).
* easing product evolution
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 04:34 PM 6/14/2002 +0200, you wrote:
> >Peter Donald wrote:
> > >
> > > Berin wrote:
> > >
> > > >ConnectionManager ssl = (ConnectionManager)
> > > > m_manager.lookup(ConnectionManager.ROLE + "/SSL");
> > > >
> > > >and this:
> > > >
> > > >ConnectionManager ssl = (ConnectionManager)
> > > > m_manager.lookup(ConnectionManager.ROLE, "SSL");
> > >
> > > Loss of clarity and added complexity.
> > >
> > > 2 extra methods that are uneeded except by Cocoon.
> >
> >I'll try to keep this abstract and I remove my cocoon hat.
>
> You didn't manage to remove you cocoon hat ;) Your arguments would make
> sense in context of Cocoons specific architectural implementation but
> generally not in other containers.
Probably. I, for one, lack the knowledge that many of you have about the
various Avalon container implementations.
> The role name is just that - an arbitrary name. ie Stephen tends to use
> names such as "socket-factory", "ssl-socket-factory" etc which are quite
> valid (even if I dislike that they no follow defacto standard). Each role
> name designates a component that satisfies certain constraints. In
> ECM/Cocoon land there is only one constraint (ie class/type of returned
> component) hence the rolename maps to class returned. In some containers
> there can be other constraints.
Ok, this is probably a context that I'm misssing, can you elaborate more
on this? It would be helpful to understand your insights.
> All of these constraints are effectively metainfo associated with a
> dependency of one component on another component. The notion of a "hint" is
> just another bit of metainfo associated with the dependency between components.
Granted.
> So why do you think it is a good idea to put some meta-data in code and
> some elsewhere?
>
> > ConnectionManager ssl = (ConnectionManager)
> > m_manager.lookup(ConnectionManager.ROLE + "/SSL");
> >
> >is a hack.
> >
> >I'm pretty sure that this is obvious to everyone.
>
> It is not clear to me. It is an arbitrary convention - I suppose I could
> have used the string "ssl-connection-manager" or "fred" or "fish-and-chips"
> but the above string follows the convention we already use.
Ok. As I said in a previous email, this 2d->1d mapping makes sense if
(and only if, I would state) the dimensionality of the lookup space is
now fixed.
I was assuming the avalon component manager had a fixed 2 dimensional
lookup space, one for roles (what), one for hints (how), since I think
this pretty much solves all possible issues.
You seem to imply this is not the case, please elaborate more.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The need for 'hints'
Posted by Peter Donald <pe...@apache.org>.
At 04:34 PM 6/14/2002 +0200, you wrote:
>Peter Donald wrote:
> >
> > Berin wrote:
> >
> > >ConnectionManager ssl = (ConnectionManager)
> > > m_manager.lookup(ConnectionManager.ROLE + "/SSL");
> > >
> > >and this:
> > >
> > >ConnectionManager ssl = (ConnectionManager)
> > > m_manager.lookup(ConnectionManager.ROLE, "SSL");
> >
> > Loss of clarity and added complexity.
> >
> > 2 extra methods that are uneeded except by Cocoon.
>
>I'll try to keep this abstract and I remove my cocoon hat.
You didn't manage to remove you cocoon hat ;) Your arguments would make
sense in context of Cocoons specific architectural implementation but
generally not in other containers.
The role name is just that - an arbitrary name. ie Stephen tends to use
names such as "socket-factory", "ssl-socket-factory" etc which are quite
valid (even if I dislike that they no follow defacto standard). Each role
name designates a component that satisfies certain constraints. In
ECM/Cocoon land there is only one constraint (ie class/type of returned
component) hence the rolename maps to class returned. In some containers
there can be other constraints.
All of these constraints are effectively metainfo associated with a
dependency of one component on another component. The notion of a "hint" is
just another bit of metainfo associated with the dependency between components.
So why do you think it is a good idea to put some meta-data in code and
some elsewhere?
> ConnectionManager ssl = (ConnectionManager)
> m_manager.lookup(ConnectionManager.ROLE + "/SSL");
>
>is a hack.
>
>I'm pretty sure that this is obvious to everyone.
It is not clear to me. It is an arbitrary convention - I suppose I could
have used the string "ssl-connection-manager" or "fred" or "fish-and-chips"
but the above string follows the convention we already use.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>