You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/16 19:22:51 UTC

[VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Folks, this is an important issue, and I would like more feedback from
someone other than Stephen and myself.

I would like us to all standardize on one library to represent the metainfo,
which also has some implications on the AMTAGS proposal as it stands.  We
have a proposal and a counter-proposal on the table, and we need to come to
consensus on the final verdict.

Proposal:

* add a new tag, @avalon.type, with the attributes "name", "version", and
   "lifestyle"
* add a new semantic for the @avalon.service tag, so that when it is declared
   in an interface the "type" attribute is not needed any more.

Counter-Proposal:

* Extend the @avalon.component tag with the attributes "name", "version", and
   "lifestyle", providing reasonable default values.
* add a new semantic for the @avalon.service tag, so that when it is declared
   in an interface the "type" attribute is not needed any more.

The only real difference between the two proposals are the use of @avalon.type
vs. @avalon.component.  Both sides have valid points, but in the end it boils
down to what the community as a whole would rather see.

@avalon.type Pro                  | Con
----------------------------------+-------------------------------------------
1) No overloading of an existing  | 1) Forces deprecation of existing tag
    tag.                           |
2) Required attributes are more   |
    easily enforced.               |


@avalon.component Pro             | Con
----------------------------------+-------------------------------------------
1) No cruft from deprecated tags. | 1) Defaults can often times cause
                                   |    questions to how things should work.

VOTE:

THis is an exclusive vote.  If you vote +1 for one approach, then that implies
-1 for the other approach.  No -1s are vetoes.

Use @avalon.type or @avalon.component?

-- 

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


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


Re: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Nicola Ken Barozzi <ni...@apache.org>.
> Berin Loritsch wrote:
>
> Use @avalon.type or @avalon.component?

+0 to avalon.component

It's more easily understandable than "type" and compatible with the old 
ones.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



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


Re: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Folks, we only have two voters on this.  It is important, and we need
> to address the issue.  Please send in your votes.

<snip/>

>> @avalon.type
 >
>> @avalon.component
>> 
>> THis is an exclusive vote.  If you vote +1 for one approach, then
>> that implies -1 for the other approach.  No -1s are vetoes.
>> 
>> Use @avalon.type or @avalon.component?

I think we need consensus rather than majority here. Since that 
apparently takes more effort than just coding it and implementing it and 
providing backwards compatibility later if you change it I say go with 
@avalon.component. All previously made  arguments apply of course :D

cheers,

- Leo



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


Re: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Berin Loritsch <bl...@apache.org>.
Folks, we only have two voters on this.  It is important, and we need to
address the issue.  Please send in your votes.

Berin Loritsch wrote:

> Folks, this is an important issue, and I would like more feedback from
> someone other than Stephen and myself.
> 
> I would like us to all standardize on one library to represent the 
> metainfo,
> which also has some implications on the AMTAGS proposal as it stands.  We
> have a proposal and a counter-proposal on the table, and we need to come to
> consensus on the final verdict.
> 
> Proposal:
> 
> * add a new tag, @avalon.type, with the attributes "name", "version", and
>   "lifestyle"
> * add a new semantic for the @avalon.service tag, so that when it is 
> declared
>   in an interface the "type" attribute is not needed any more.
> 
> Counter-Proposal:
> 
> * Extend the @avalon.component tag with the attributes "name", 
> "version", and
>   "lifestyle", providing reasonable default values.
> * add a new semantic for the @avalon.service tag, so that when it is 
> declared
>   in an interface the "type" attribute is not needed any more.
> 
> The only real difference between the two proposals are the use of 
> @avalon.type
> vs. @avalon.component.  Both sides have valid points, but in the end it 
> boils
> down to what the community as a whole would rather see.
> 
> @avalon.type Pro                  | Con
> ----------------------------------+------------------------------------------- 
> 
> 1) No overloading of an existing  | 1) Forces deprecation of existing tag
>    tag.                           |
> 2) Required attributes are more   |
>    easily enforced.               |
> 
> 
> @avalon.component Pro             | Con
> ----------------------------------+------------------------------------------- 
> 
> 1) No cruft from deprecated tags. | 1) Defaults can often times cause
>                                   |    questions to how things should work.
> 
> VOTE:
> 
> THis is an exclusive vote.  If you vote +1 for one approach, then that 
> implies
> -1 for the other approach.  No -1s are vetoes.
> 
> Use @avalon.type or @avalon.component?
> 


-- 

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


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


Re: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Stephen McConnell <mc...@apache.org>.

Berin Loritsch wrote:

> The only real difference between the two proposals are the use of 
> @avalon.type
> vs. @avalon.component.  Both sides have valid points, but in the end 
> it boils
> down to what the community as a whole would rather see.
>
> @avalon.type Pro                  | Con
> ----------------------------------+------------------------------------------- 
>
> 1) No overloading of an existing  | 1) Forces deprecation of existing tag
>    tag.                           |
> 2) Required attributes are more   |
>    easily enforced.               |


+1

>
>
> @avalon.component Pro             | Con
> ----------------------------------+------------------------------------------- 
>
> 1) No cruft from deprecated tags. | 1) Defaults can often times cause


-1

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Re: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Peter Royal <pr...@apache.org>.
On Wednesday, July 16, 2003, at 01:22  PM, Berin Loritsch wrote:
> @avalon.component Pro             | Con
> ---------------------------------- 
> +-------------------------------------------
> 1) No cruft from deprecated tags. | 1) Defaults can often times cause
>                                   |    questions to how things should  
> work.
>

+1 for @avalon.component.

I don't like the nomenclature for @avalon.type
-pete


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


[RESULTS] @avalon.type or @avalon.component

Posted by Berin Loritsch <bl...@apache.org>.
The results of the vote for which name to give the type/component info is:

@avalon.type
     mcconnell

@avalon.component
     proyal, czeigler, vinay

Note: nicolaken was +0 on @avalon.component

Considering that I am also for @avalon.component, it seems that that name
one the vote.

I will make the code change ASAP.

-- 

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


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


RE: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Vinay Chandran <vi...@yahoo.com>.
> Use @avalon.type or @avalon.component?
+1 on @avalon.component

Regards,
@vinay

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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


RE: [VOTE] Updating AMTAGS with @avalon.type or @avalon.component

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> Use @avalon.type or @avalon.component?
> 
+1 for @avalon.component

Carsten


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