avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Minimum Set of Tags (Revisited)
Date Tue, 08 Apr 2003 17:24:00 GMT

Berin Loritsch wrote:

> Stephen McConnell wrote:
>> Berin Loritsch wrote:
>>> This is not the time to decide what namespace (i.e. @avalon.*)
>>> you think a tag should be, but what the actual name and attributes
>>> should be (i.e. @*.name attr="foo").
>> It is also the time to state with clarity the purpose of this 
>> iniative.  My assumption is that we are working towards the defintion 
>> of a set of tags that can be used independenly of any container to 
>> provide the supplimentary meta info needed for any container to 
>> either deply the component, or signal an inability to deploy.
> It is the minimum set of tags that are required to *define* a component
> and its role interfaces.  The minimal set is not intended to provide
> any information that is used for validation purposes.  There is no
> notion of signaling the container that they cannot deploy the component.

If this does not include sufficient content to let me (as a developer) 
deploy a component in a container independent manner, or me (as a 
container author) to interprit these tags in a manner that provides at 
least basic integrity - then I fail to see the utility.  What this means 
is that for every sinple semantic defined across merlin and phoenix and 
fortress that is not defined in the @avalon space, you need declare to a 
developer and container authors, hat the expected semantics are and 
getting agreement. This will not happen unless we get into recognition 
of semantics that are assumed in some environemts - e.g. lifestyle 
assumptions in merlin, phoenix and fortress are different and yet the 
notion exists in all three and yet we are not dealing with it. This does 
not make sence to me.

>>> My understanding (after the discussions with Peter and Stephen are):
>>> 2) Phoenix use of @avalon.service and Merlin use differ.  The
>>>    semantics of the type name differ.
>>>    * Version should not be encoded (Merlin), but specified seperately. 
>> I disagree - but I'm willing to accomadate the change.
>> :-)
> I take the approach of *Say What You Mean*.  I don't want to have to
> interpret a meaning from any text.  In the case of encoding the version
> into the type name, you are incoding additional information which means
> the type name is interpreted instead of declared.

Whatever - if the samentics of the interprited string are clear and 
unambigouse then its not an issue (see URL and URI protocols as 
examples).  My experience has been that the 
<classname><deliminter><version> is functional, usable, and 
understandbale in practicle and works well (better than the 
class/version seperation).  It is used throught Merlin, the Assembly 
system, and the Meta model.  It is no different from any other string 
representation of a more complex thing.  In you case you are dealing 
with simple classes, in my case I am dealing with TYPEs, and types are 
not the same as simple classes - they have versions.  If you want to say 
what you mean that you should say class="xxx" version="yyy".

As I said - as far as getting to a common defintion is concerned - while 
I disagree with your comment - I can accomadate it. 

>>> 3) Dislike of the @avalon.component/@avalon.role
>>>    * Boils down to personal style 
>> Disagree.
>> I think this is more about content - not usage.
> ?? 

See earlier email on this point.
The existance of an interface with supplimentary information defines 
exactly that - an interface package with suppliementary information.  It 
is not the same as a usage directive.

>>>    * Any component that implements a role interface supports that
>>>      service (According to Framework 4.0 standards). 
>> Disagree.
>> This is a usage constraint that is implied by AF4.

See earlier email - I meant to say that this is NOT implied by AF4.

> And unless you know something that I don't, we are still supporting
> AF4.  I haven't noticed a AF5 yet....
> What purpose would there be for a component implementing a role
> interface if it was not to provide that service?

It may instantiate other components and provide itself as a reference to 
those components (e.g. helper classes).  This does not imply that the 
interface should be exposed as part of the public services.  That is a 
developer decision.  I have many cases of interfaces that are used in 
different scenarios - some of those scanerois are related to service 
export, others are related to internal machinery.

> If there is a defined role interface like this:
> interface EchoService
> {
>     String echo(String message);
> }
> If I later defined a component that implements this interface:
> class EchoComponent implements EchoService
> {
>    //....
> }
> My intention is to provide that service.  Isn't that clear?

It is clear that you implement the service.
It is not clear that your intention is to export that service.

> Why would I implement that interface if I didn't want to provide
> that service?  I can't possibly think of a reason.

I do this oftern - about 20% of the time.  I have all sorts of 
interfaces, but I'm very strinct about exporting.  If I want to export a 
service I want that export to be explicitly declared - not implied.  If 
I were forced to do adopt the model you are describing I would have to 
duplicate may interfaces just to seperate the notion of usage from contract.

No thanks!


> That is not to say that components are relegated to only one service.
> They are not.  One component can implement several services.

But today the component controls what it exports and its iindepdent of 
the implements clause.

>>>    * Whether that role interface is specified by @avalon.service
>>>      or @avalon.role is irrelevant.
>> Disagree.
>> The notions are quite different.  One is declaration of an interface 
>> as a work interface as distrinct for the potential to use the same 
>> interface in other non-work related situation.  The other is an 
>> explicit statement of the exposure of a service by a component.  
>> Implementation of a service is not the only way a component can 
>> deliver a service.  In Merlin land I have components the dliver 
>> services but do implement the service interface.  You need to make 
>> sure that assumptions you put into a tag do not imply implementation 
>> decisions.
> If you misuse contracts which have been long established, why should I
> be punished? 

What contracts!
If you imply semantics that don't exist, why should be punished.

>>> I prefer marking the
>>>      role interface unless it is not available in the JAR,
>>>      Stephen and Peter prefer marking the component implementation.
>> The two are orthoginal.  If I under you correctly you want to make 
>> the assumption that if an interface that has been marked as a role is 
>> implemented by a component, then you can infur that the component 
>> exposts that interface as work interface.  I disagree with this 
>> assumption.
> This is a CONTRACT that has been around and agreed upon from Avalon
> Framework 4.0.  

Wow .. slow down.
When was this agreed to?. 
Where is this documeted?

Reality check - this is not part of the contract.

> We HAVE NOT OUTGROWN these contracts in 4.1.  

Correct - they never existed therefore they cannot be outgrown.

> We merely
> gained the ability to declare a component that did not implement the
> Component interface.  We also "technically speaking" provided the
> ability to have components without a declared interface as the work
> interface (i.e. incorporating CORBA objects into the ServiceManager
> lookup).

It is interesting to note that the example you site is a case of a 
service interface that (a) is not a interface, and (b) cannot implement 
a contract your suggesting exists.

> However, under no circumstances do I recall us as a community rescinding
> the contract that a work interface is for the express purpose of
> defining the contract that a component operates under.  Therefore any
> component that implements the work interface does it to provide that
> service.

I'm really sorry, but I disagree.  There is very big difference between 
defining contract (interfaces, meta, etc.) as distinct from the 
machinery used to delivery services in accordance with that contract.  
We are talking about statements that deal with the contractual defintion 
- we are not taklking about implementation.  The usage of an 
"implements" keyword does not man I'm expoosing that service.  I have 
components that expose services and those component do not implement or 
extend the service.  I have components that implement interfaces but do 
not expose them as services.  I have components that implement 
interfaces and expose these are services.  Please - all of these are 
viable option and options that should ber respected.

>>> One thing I would like to propose is a change to @avalon.component
>>> which would do away with a need for @x-avalon.name:
>>> @avalon.component name="my-component-name" 
>> You can enhance this to cover the component implementation version 
>> declaration with the following:
>> @avalon.component name="whatever" version="1.2.3"
> Sure.
>>> Alternatively, if we want the "extension" semantic to make it
>>> clear that the attribute is optional:
>>> @avalon.component x-name="my-component-name"
>> What does "optional" mean. Does it mean that I can ignore it without 
>> compromizing the componet?
> Yes.

Good - I may quote you on this as we move forward.

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message