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...@d-haven.org> on 2004/03/18 15:09:50 UTC
Ist it just me? (was Re: [Meta] Confused by the terms)
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
> -----Mensagem original-----
> De: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
>
>>Now, we could argue about the correct terms for months but the
>>term "type" is imho misleading here. If a type exposes all
>>features of a component why is it called a type and not
>>component?
>
>
> Its a TypeDescriptor. Something like "for class X there are these
> dependencies, these custom lifecycles" and so on.
Here in lies one of the fundamental problems I have with the
Meta package. If there is this much discussion about it with
people who are Avalon veterans, then something is seriously
wrong. It is too complex, and introduces too many new concepts
that we haven't bought off on.
This is a "code smell" or at least a "design smell".
That is also part of the reason I continually try to push simpler
solutions like Commons Attributes or JDK 1.5 annotations. The
bottom line is it should not be this hard.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Ist it just me? (was Re: [Meta] Confused by the terms)
Posted by peter royal <pr...@apache.org>.
On Mar 18, 2004, at 9:09 AM, Berin Loritsch wrote:
> Here in lies one of the fundamental problems I have with the
> Meta package. If there is this much discussion about it with
> people who are Avalon veterans, then something is seriously
> wrong. It is too complex, and introduces too many new concepts
> that we haven't bought off on.
+1
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Ist it just me? (was Re: [Meta] Confused by the terms)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 18 March 2004 22:40, Leo Sutic wrote:
> What should we drop? (Note: "drop in a backwards-compatible way" - i.e.
> not abandon our users.)
>
> + The XML format.
>
> The XML format should be dropped - if we have an API to access it, it
> shouldn't matter what the underlying format is.
I somewhat disagree...
I am really keen on a definition that can be expressed in RDF. RDF is per
definition not XML, although the most common external format is in XML, and
possibly the only one accepted across the board, I would tend to believe that
it is required to have a 'queryable' external 'interface' for components and
services.
Why should we use RDF for Meta information?
Because its principle is so simple, yet powerful enough to express what we
need, and interact with other tools, most notably RDF search engines.
Subject Predicate Object
If you know any grammar at all from school, you will know that much.
Ex;
ComponentInstance InstanceOf ComponentType
ComponentType HasName Name
ComponentType HasVersion Version
ComponentType Implements ServiceInterface
and so on. Fairly easy to express and discuss around as well.
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
RE: Ist it just me? (was Re: [Meta] Confused by the terms)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Berin Loritsch
>
> Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
>
> > -----Mensagem original-----
> > De: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> >
> >>Now, we could argue about the correct terms for months but the term
> >>"type" is imho misleading here. If a type exposes all features of a
> >>component why is it called a type and not component?
> >
> >
> > Its a TypeDescriptor. Something like "for class X there are these
> > dependencies, these custom lifecycles" and so on.
>
> Here in lies one of the fundamental problems I have with the
> Meta package. If there is this much discussion about it with
> people who are Avalon veterans, then something is seriously
> wrong. It is too complex, and introduces too many new
> concepts that we haven't bought off on.
>
> This is a "code smell" or at least a "design smell".
I think there are parts of Meta that we have already accepted,
and parts we haven't accepted.
What we have accepted, at least partly, is that we should have
*something* that is "java.lang.reflect for Avalon". I.e. some
way to access Avalon-specific metadata about components, interfaces
etc.
We also have sort-of consensus what should go into that metadata.
For example, we want to be able to define:
+ Dependencies
+ Versions
+ Context requirements
I think we have consensus on the above.
What we don't have consensus on is the way that data is
+ Specified in the source code / extra files
+ collected during the build process
+ accessed at runtime
and this is where the conflicts are.
Otherwise, we're pretty much in agreement. For example:
Avalon Meta:
@avalon.security.permission class="java.util.PropertyPermission"
name="java.version" actions="read,write"
Commons-Attributes:
@@PermissionDescriptor(java.util.PropertyPermission.class,
"java.version",
new String[]{ "read", "write" })
However, the way the metadata is specified, collected and accessed
differs vastly between Avalon Meta and Commons Attributes.
So what should be kept from Avalon Meta?
+ The model. OK, maybe we should rename Type to Component, and lose
the -Descriptor ending. I mean, its java.lang.Class and not
java.lang.ClassDescriptor, after all. But I think the model
captures a lot of good stuff.
What should we drop? (Note: "drop in a backwards-compatible way" - i.e.
not abandon our users.)
+ The XML format.
The XML format should be dropped - if we have an API to access it, it
shouldn't matter what the underlying format is.
Class myComponentClass = ...;
Type t = new Type (myComponentClass);
Should be all.
+ The current collection process.
The current builder only recognizes tags it is programmed to
recognize. This is a problem, since it means you have to modify
the build process in order to add a tag (that you may want to experiment
with). The collection process should just gather *all* tags, and
leave it to runtime to interpret them.
Note: This does not mean that the tags can't be validated for internal
consistency during buildtime.
+ Maybe reduce coupling inside the model. It makes for difficulty in
extending it. For example, you can't get the SecurityDescriptors
from the Type class. In Commons-Attributes you'd do:
Attributes.getAttributes (myComponentClass,
PermissionDescriptor.class);
Instead of accessing everything via the Type class. This means that
if you add a descriptor class, you don't have to extend the
Type class in order to access it.
+ I really don't like the generic Descriptor class either.
Not typesafe enough with its getAttributeNames method.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org