You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/08/23 13:16:00 UTC
Attribute naming?
Hi,
I am starting to go through and document the attribute naming scheme for
phoenix and other containers and I am wondering what the preferred naming
convention is. Attributes are the mechanism via which components can supply
"extended" information to the container for various aspects of their
management.
Each attribute is made up of two parts, a local name and a namespace. The
namespace separator is either ":" or ".". So mx.enable is equivelent to
mx:enabled
The kind of things that are going to end up as attributes include things like
avalon.stateless=true|false (is the component/service stateless?)
avalon.thread-safe=true|false (is the component/service threadsafe?)
avalon.reentrant=true|false (is the component/service reentrant?)
avalon.pass-by-value=true|false (does the service follow pass by value
semantics?)
mx.enabled=true|false (is the service a management service?)
mx.proxy=com.biz.MyProxy (specify my management proxy)
...
My question is the best naming convention for the attributes?
My initial perceptions are that you should name the namespaces either
1. according to the name of container the supports extension (if container
specific)
2. according to well known shortening conventions (ie mx for management, tx
for transaction, sec for security) if (1) no apply
3. According to their logical concepts if neither (1) nor (2) apply. (ie
partion for partion attributes or component for component attributes).
However my impression is that local names should be full english names. ie you
use the "pass-by-value" local name rather than "pbv" or any other shortening.
This will have an effect on the verbosity of the javadoc that is used to
markup a class. For example to makr a component as thread safe you could end
up having to mark them as
/**
* @avalon.component avalon.threadsafe="true"
*/
which may be a litte verbose. Anyone got any better ideas? Or any further
preferences.
Currently I am just documenting attributes that are cross container and adding
examples of container specific ones or toolkit specific ones. ie The above
all work plus we have things like
altrmi.rate=500
altrmi.reconnect=4
instrument.name=bob
etc.
However these attributes are generally ties to a sepcific container or
specific toolkit/extension. And thus are free to be changed by the authors of
specific extension etc.
Anyways, can anyonje see any issue with these naming conventions? I am not
specifying the syntax of the values using any formal method as I belive that
informal methods will make it easier to evolve - at least intiially.
Thoughts?
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>
>
><snip/>
>
>
>
>>>This will have an effect on the verbosity of the javadoc
>>>
>>>
>>that is used
>>
>>
>>>to
>>>markup a class. For example to makr a component as thread
>>>
>>>
>>safe you could end
>>
>>
>>>up having to mark them as
>>>
>>>/**
>>> * @avalon.component avalon.threadsafe="true"
>>> */
>>>
>>>which may be a litte verbose. Anyone got any better ideas? Or any
>>>further
>>>preferences.
>>>
>>>
>>see above. I'm totally okay with this level of verbosity; it
>>is similar to the level of verbosity in java or xml.
>>
>>
>
>I prefer the use of enumerated values for this. We are talking about
>lifestyle, which has specific meaning.
>
>I much prefer simething like:
>
>@avalon.component lifestyle="threadsafe"
>
>as opposed to having a set of related attributes that are true/false.
>Esp. if those related attributes are mutually exclusive.
>
>
>
>>convention is good; solid definition of convention is better.
>>Actually supporting syntactic meaning on the basis of
>>convention...we're all against doing that I guess.
>>
>>I like the ":" for separation of namespace from meaning.
>>
>>
>
>
>Traditionally the ":" is a namespace separation, so it would be
>good to reenforce that. XML, C++, CORBA IDL, Perl, and several
>other languages use the ":" for the purpose of namespace separation.
>It would only be natural for us to use it that way.
>
>We use the "." as a separator for categories in LogKit, so that
>precedence would work for the rest of Avalon attributes. I know
>many XML schemas that us the "-" as the word separator, and it
>is largely a matter of style (the "." is also legal for the same
>purpose in XML).
>
>
Would it be reasonablke to summarise this as:
<domain>:<context>.<content>.<ontext>
etc. Where a context is
<word>-<word>-<words>
As in
osm.net:planet.referal-service
Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>>>>/**
>>>> * @avalon.component avalon.threadsafe="true"
>>>> */
>>>>
>>>>
>>I prefer the use of enumerated values for this. We are talking about
>>lifestyle, which has specific meaning.
>>
>>I much prefer simething like:
>>
>>@avalon.component lifestyle="threadsafe"
>>
>>as opposed to having a set of related attributes that are true/false.
>>Esp. if those related attributes are mutually exclusive.
>>
>>
>
>+1
>
dito +1
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Attribute naming?
Posted by Leo Simons <le...@apache.org>.
> > > /**
> > > * @avalon.component avalon.threadsafe="true"
> > > */
>
> I prefer the use of enumerated values for this. We are talking about
> lifestyle, which has specific meaning.
>
> I much prefer simething like:
>
> @avalon.component lifestyle="threadsafe"
>
> as opposed to having a set of related attributes that are true/false.
> Esp. if those related attributes are mutually exclusive.
+1
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Peter Donald <pe...@apache.org>.
On Sat, 24 Aug 2002 00:59, Berin Loritsch wrote:
> I prefer the use of enumerated values for this. We are talking about
> lifestyle, which has specific meaning.
>
> I much prefer simething like:
>
> @avalon.component lifestyle="threadsafe"
The problem is that this approach removes control from the container. The
notion of threadsafe as propogated by ECM is different from the classical
notion of threadsafe and is actually a composite notion that can be made up
of parts. So I believe it is much better to separate out each meta data
aspect into different attributes. A little more verbose (2 vs 1 for standard
threadsafe component) but far more useful for the container.
> > convention is good; solid definition of convention is better.
> > Actually supporting syntactic meaning on the basis of
> > convention...we're all against doing that I guess.
> >
> > I like the ":" for separation of namespace from meaning.
>
> Traditionally the ":" is a namespace separation, so it would be
> good to reenforce that.
The probalems essentially aruises that "." is the separator for xdoclet and
javadoc based tools. If we don't allow it then we end up with substantial set
of errors when building javadocs. However id we allow "." then we can exclude
the tags based on commandline option.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Attribute naming?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
<snip/>
> > This will have an effect on the verbosity of the javadoc
> that is used
> > to
> > markup a class. For example to makr a component as thread
> safe you could end
> > up having to mark them as
> >
> > /**
> > * @avalon.component avalon.threadsafe="true"
> > */
> >
> > which may be a litte verbose. Anyone got any better ideas? Or any
> > further
> > preferences.
>
> see above. I'm totally okay with this level of verbosity; it
> is similar to the level of verbosity in java or xml.
I prefer the use of enumerated values for this. We are talking about
lifestyle, which has specific meaning.
I much prefer simething like:
@avalon.component lifestyle="threadsafe"
as opposed to having a set of related attributes that are true/false.
Esp. if those related attributes are mutually exclusive.
> convention is good; solid definition of convention is better.
> Actually supporting syntactic meaning on the basis of
> convention...we're all against doing that I guess.
>
> I like the ":" for separation of namespace from meaning.
Traditionally the ":" is a namespace separation, so it would be
good to reenforce that. XML, C++, CORBA IDL, Perl, and several
other languages use the ":" for the purpose of namespace separation.
It would only be natural for us to use it that way.
We use the "." as a separator for categories in LogKit, so that
precedence would work for the rest of Avalon attributes. I know
many XML schemas that us the "-" as the word separator, and it
is largely a matter of style (the "." is also legal for the same
purpose in XML).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-08-23 at 13:16, Peter Donald wrote:
> Hi,
hi :)
> I am starting to go through and document the attribute naming scheme for
> phoenix and other containers and I am wondering what the preferred naming
> convention is.
where possible the convention should be reflective of conventions in
java itself.
> My question is the best naming convention for the attributes?
it seems there are two 'separators' in use: "." and ":". I suggest usage
of the two is defined clearly.
. word separator
: semantic content information separator
ie it seems there are multiple pieces of information inside an attribute
at times. Stephen has identified the domain, there might be others
(though I can't nor want to think of any).
The format becomes
([a-z]*.?)*:([a-z]*.?)*
(or something, I suck at regexp).
with the first part defining the domain and the second part the key.
Note everything is in lowercase.
examples:
avalon.meta:lifestyle = perthread
avalon.meta:pass.by.value = true
mx:enable = true
mx:secure = false
an alternative is to use the "." as the domain separator and the "-" as
the word separator
([a-z]*.?)*:([a-z]*-?)*
example:
avalon.meta:pass-by-value = true
I don't really care. I suggest the key is otherwise freeform, and that
the domain is mostly analogous to package naming. (avalon.meta refers to
org.apache.avalon.meta, or perhaps org.apache.avalon.framework.meta).
>
> My initial perceptions are that you should name the namespaces either
> 1. according to the name of container the supports extension (if container
> specific)
+1
> 2. according to well known shortening conventions (ie mx for management, tx
> for transaction, sec for security) if (1) no apply
+1
> 3. According to their logical concepts if neither (1) nor (2) apply. (ie
> partion for partion attributes or component for component attributes).
I'd suggest defaulting to package naming instead, and resorting to
logical concepts only after that.
> However my impression is that local names should be full english names. ie you
> use the "pass-by-value" local name rather than "pbv" or any other shortening.
+1
> This will have an effect on the verbosity of the javadoc that is used to
> markup a class. For example to makr a component as thread safe you could end
> up having to mark them as
>
> /**
> * @avalon.component avalon.threadsafe="true"
> */
>
> which may be a litte verbose. Anyone got any better ideas? Or any further
> preferences.
see above. I'm totally okay with this level of verbosity; it is similar
to the level of verbosity in java or xml.
> Anyways, can anyonje see any issue with these naming conventions? I am not
> specifying the syntax of the values using any formal method as I belive that
> informal methods will make it easier to evolve - at least intiially.
>
> Thoughts?
convention is good; solid definition of convention is better. Actually
supporting syntactic meaning on the basis of convention...we're all
against doing that I guess.
I like the ":" for separation of namespace from meaning.
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Friday, August 23, 2002 8:45 PM
Subject: Re: Attribute naming?
>
>
> Peter Donald wrote:
>
> >Hi,
> >
> >I am starting to go through and document the attribute naming scheme for
> >phoenix and other containers and I am wondering what the preferred naming
> >convention is. Attributes are the mechanism via which components can
supply
> >"extended" information to the container for various aspects of their
> >management.
> >
> >Each attribute is made up of two parts, a local name and a namespace. The
> >namespace separator is either ":" or ".". So mx.enable is equivelent to
> >mx:enabled
> >
>
> I prefer the <domain>:<key> approach.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attribute naming?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>Hi,
>
>I am starting to go through and document the attribute naming scheme for
>phoenix and other containers and I am wondering what the preferred naming
>convention is. Attributes are the mechanism via which components can supply
>"extended" information to the container for various aspects of their
>management.
>
>Each attribute is made up of two parts, a local name and a namespace. The
>namespace separator is either ":" or ".". So mx.enable is equivelent to
>mx:enabled
>
I prefer the <domain>:<key> approach.
For example in the Merlin/Fortess work there is a avalon:lifestype
attribute.
the domain is "avalon"
the key within the avalon domain is "lifestyle"
Another example could be :
osm.net:redirection-address
Using the colon to seperate domain from key seems to me to be a
practical approch because its possible to seperate domain and key in
things like editors.
>
>The kind of things that are going to end up as attributes include things like
>
>avalon.stateless=true|false (is the component/service stateless?)
>avalon.thread-safe=true|false (is the component/service threadsafe?)
>avalon.reentrant=true|false (is the component/service reentrant?)
>avalon.pass-by-value=true|false (does the service follow pass by value
>semantics?)
>mx.enabled=true|false (is the service a management service?)
>mx.proxy=com.biz.MyProxy (specify my management proxy)
>...
>
A lot more import that the names will be the samantics that are implied
by the attributes towards containers. What the above sort of things
imply needs to be detailed really carefully as part of an over container
interoprability specification. For example, the Merlin/Fortress work
has has resolved a common lifestyle model in which "avalon:lifestyle"
has a set of documented values that determin the approapriate lefestyle
handler to apply to a component.
Common interfaces and abstract classes supporting those areas that have
been resolved (at least with Merlin and Fortress) have been moved to an
independent project ecalibur/container project. As we move forward
with the resolution of other attribute names and comoon semantics (as
per the lifestyle extensions approach), the related resources can be
added to excalibur/container.
Another example is avalon:home - its a context key used to resolve the
base working directory. It reasonable to assume that Merlin, Fortress
and Phoenix could converge on the same naming convention - and
potentially use common utility interfaces (for example: a context
interfaces for access the base directory and component name).
I'm currently working on the xdocs for the excalibur/container content.
I want to include in that pages detailing common meta-info and context
attributes usable across different container implememtations, together
with the availability and level of support in specific containers.
This should be available shortly.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>