> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > 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). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
