avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: Service and other Terminology
Date Sun, 01 Sep 2002 20:16:03 GMT
> >block: deprecated alias for component
> >
> Agree that deprecation as a term is possible.  It was not the 
> only thing 
> called component though in the context of the Avalon project.

Yup.

> >component: A passive entity that performs a specific role
> >  
> >
> Refer also to patterns to complete story.

Hmm. I'd say the definition list should be self-contained, and
The pattern documentation should refer to0 the definition list.

> >consumption: the usage by a component of a service
> >
> -1 ... it is a new term.

No term currently in use is satisfactory as pointed out by others
in recent discussion. The goal here is to remove ambiguity and
define one common set of terms for use throughout the project.

> >entity: part of the computer hardware and/or software system
> >
> -1 .... over used.

The term is used in many places throughout the docs and
the code. Hence, we should provide a definition. The definition
I chose matches the dictionary and fits current term usage.

> >metadata: the complete set of specifications of component types, 
> >component profiles and service definitions
> >
> Personally I find the term 'metadata' and 'meta' too ambiguous.  I'd 
> prefer to see 'Component Metadata'.

The issue is when you consider service metadata where service is
distinct from component. Current metadata proposals mix component
and service metadata hence I feel component metadata is
inappropriate.

> >profile: the combination of the specification of resources 
> consumed by 
> >a component at runtime and the type applicable to the component
> >
> -1 ... it is a new term.

The term is neccessary to completely define a component metadata
model specification unambiguously. It is also already in use.

> >provision: the supplying of a service implementation
> >
> -1 ... it is a new term.

No term currently in use is satisfactory as pointed out by others
in recent discussion. The goal here is to remove ambiguity and
define one common set of terms for use throughout the project.

> >resource: any entity or combination of entities
> >
> -1 ... it is a new term. And it is overused.

The term is used in many places throughout the docs and
the code. Hence, we should provide a definition. The definition
I chose refers to another term and will enable people that
wonder what we mean in our current documentation to better
Understand the 'generalism' in use here.

> >role: the key by which a service is referenced at runtime
> >
> Hoping for simplification to key.

Hmm. I think just "key" is a little too generic; and it is in
use in multiple places (it can also refer to a "key" inside a
Context or Parameters object). A possibility is "service key",
but since role has been in use for a long time I suggest we
keep it. This is especially important as it is also in use
directly inside a lot of client code in the form of
<<classname>>.ROLE.

> >type: the combination of a service specification and a dependency 
> >specification
> >
> -1 ... it is a new term.

The term is neccessary to completely define a component metadata
model specification unambiguously. It is also already in use.

> >work interface: a java interface specifying component 
> functionality (as 
> >opposed to specifying component behaviour)
> >
> -1 ... it is a new term.

The term is neccessary to completely define a component metadata
model specification unambiguously. It is also already in use.

I disagree with you on the notion that there are "new terms"
introduced in the above list. All of them are in use in various
software systems, and most of them already in use inside avalon,
though perhaps not inside the avalon framework documentation.

I would rather define more terms than will actually be used as
opposed to defining only a few terms resulting in proliferation
of author- or subproject-specific terminology (ie the current
Situation). I would also rather define new terms than use
inappropriate terms. I consider backwards compatibility in
terminology to be not *that* much of an issue as we basically
have very few terms neatly defined atm.

Where it is possible to use existing terms we should do so,
however.

Oh, and sorry for sounding like a machine in the above post,
but I figured this would be the most productive ;)

cheers,

Leo



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


Mime
View raw message