avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT] SOC & Meta Information
Date Wed, 04 Sep 2002 18:51:13 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > 
> > Anyway, very nice! :-D
> > I also think that some of these can be checked compiletime, like
> > stateless I think.
> > 
> > Some considerations:
> > 
> > - avalon:activation  I don't understand the implications
> > completely, and 
> > we would need to define what a "partition" is, as said in 
> > previous mails.
> > 
> > - feature:required   I think I prefer this to feature:featurename, 
> > because it specifies if it's required, without semantics on how to
> > declare it
> > 
> > - What's the difference between doc:description-key and
> > doc:i18n-bundle? 
> > Can't we simply supply i18n bundles for the descriptions? 
> If instead 
> > it's for the component to supply its i18nzed strings, it's 
> > not a doc: ...
> > 
> > I think I like this :-)
> > One thing is that I would like to see maybe
> > 
> >    avalon:activation ->  avalon:lifestyle.activation
> >    feature:required  ->  avalon:feature.required
> >    doc:description   ->  avalon:doc.description
> > 
> > or something like it, to prevent nasty clashing with eventual
> > additional 
> > javadoc tags being used (especially feature and docs that are 
> > common words).
> 
> 
> Another set of attributes that would make sense would be if certain
> components *could* be integrated into a SEDA style architecture.  In
> Avalon land, we are calling it SILK for the time being.  We can wrap
> traditional components with a SEDA stage, which would interpret the
> events and send them to the component in question.  Since the stage
> becomes a special client, the attributes are toolkit specific: i.e.
> if a container supports SEDA, then use this Stage class....  The
> important thing here is that any SEDA compliant implementation must
> be threadsafe/reentrant/sharable (at least currently).


I forgot to post the attribute that would be *Service* specific:

silk:stage-class = ........

Of course things could be reversed and the Stage would be treated as
a first class type, which would depend on the referenced component....


--
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