You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Hamilton Verissimo de Oliveira (Engenharia - SPO)" <ha...@agenciaclick.com.br> on 2004/03/18 15:39:29 UTC
[Avalon Meta] [short RT] Attributes/Object model
Despite all the ego-conflict in recent discussions I also believe the
attributes defined in the meta package today is almost everything we need
for any container implementation [1]. I think having an object model that
describes the components is a necessity for any container.
However the way meta is collected and stored could be different for any
container. The current implementation is Merlin specific (xinfo/xprofiles
don't fit in other worlds) so looking at the fine post from LSimons
(http://jroller.com/page/lsd/20040304#rethinking_attributes), the way info
is collect can be plugged.
By using this approach no tools for "bridge" everything != Merlin to
standard Meta would be necessary. The pros and cons of using
commons-attributes should be brough to the table, also the fortress
approach. Nobody would get hurt or killed :-)
--
hammett
[1] I don't see an usage for Version attribute of Service/Component tag, and
Service tag either. The meta could be a simple set of *simple* attributes,
and be extended by those who want it. By now, these information can be made
optional in the object model, and we go from there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Avalon Meta] [short RT] Attributes/Object model
Posted by Stephen McConnell <mc...@apache.org>.
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
> [1] I don't see an usage for Version attribute of Service/Component tag, and
> Service tag either. The meta could be a simple set of *simple* attributes,
> and be extended by those who want it. By now, these information can be made
> optional in the object model, and we go from there.
An interface can go though version changes without necessarily impacting
its signature. In effect version on a service captures the semantic and
computation contract of the service. In turn, service version
information is used when potential candidate component types with
versioned service dependencies exposed by a component.
It's rather fine grain - but essential when your dealing with standards
based generated interface backed by component implementations that
implement a particular semantic and computational version (think
CORBA/IIOP, IDL, and PSDL generated content).
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Avalon Meta] [short RT] Attributes/Object model
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 18 March 2004 22:39, Hamilton Verissimo de Oliveira (Engenharia -
SPO) wrote:
> However the way meta is collected and stored could be different for any
> container.
Sorry, I think you missed the mark.
A component is in my world packaged, ready for use, without source, without
manual fiddling with it, and going into any container today and for the next
10 years. Your suggestion of "collection and storage being container
specific" doesn't cut it.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org