avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [proposal] avalon 5 ComponentManager interface
Date Mon, 17 Jun 2002 23:06:32 GMT
Peter, you still haven't addressed the scenario #5 from the
COmponentManager
use case thread.

How do you propose to do it?

And don't tell me write a XXXManager component--what difference is
between
that and the ComponentSelector?

Please, enlighten me.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org] 
> Sent: Monday, June 17, 2002 6:55 PM
> To: Avalon Developers List
> Subject: Re: [proposal] avalon 5 ComponentManager interface
> 
> 
> At 11:10 PM 6/17/2002 +0200, you wrote:
> > > Hmm ... considering you have described an architecture 
> that solves 
> > > this this sounds like bandstanding. A4 is here to stay then.
> >
> >I don't get it.
> >
> >Are you saying that you'd like to throw away the entire A5 concept 
> >because of
> >
> >  lookup(role,hint)
> 
> largely. If A5 is to exist it should correct all known 
> problems. One of the 
> biggest problems has arisen because people have been misusing avalon 
> interfaces. Hint is metadata associated with a dependency - 
> you still have 
> not answered why you feel the need to place metadata in both code and 
> configuration files?
> 
> Remember that there was once a belief that ThreadSafe and 
> other marker 
> interfaces were "absolutely essential" for a scalable system. 
> Now they are 
> considered a hack because they put metadata into both code 
> and descriptors. 
> Note that ComponentSelectors are now also considered a hack - 
> partially 
> because they put metadata in both code and descriptors. 
> Finally there is 
> the Component interface - it is now considered a hack as it 
> puts metadata 
> in both code and descriptors. This is not to mention all 
> those other things 
> that I managed to win (Poolable + Recyclable are not in 
> framework, ECM is 
> not in framework etc) who commit similar crimes.
> 
> Note that each of these features (except Component) were considered 
> "absolutely essential" features and without them Cocoon would 
> be crippled, 
> the sky would fall and blah blah blah. I pointed out back 
> then that they 
> are going to limit scalability and adversly effect 
> maintainability but I 
> was told I was wrong. However it turns out that Cocoon 
> developers later 
> came to the same conclusion that I did and more than one has 
> blamed Avalon 
> for the problems where the fault really lies with Cocoon 
> developers. Don't 
> be blinded by current implementation strategy or else the 
> same thing will 
> occur again in another 6 months.
> 
> >where we *explicitly* state that the container is safely allowed to 
> >ignore the hint?
> 
> because some will not ignore the writing because they see 
> containers such 
> as cocoon ignoring the writing. Cocoon already treats hints 
> as constraints 
> and not hints - I cant see that as changing because the 
> concept is not 
> clear or simple. Even Berin has confused the issue a couple 
> of times and 
> presumably he knows what he is talking about.
> 
> 
> 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:   
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 


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


Mime
View raw message