avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Context Entries
Date Tue, 22 Jul 2003 20:45:19 GMT
Stephen McConnell wrote:

> Berin Loritsch wrote:
> 
>> I am hoping we were just crossing signals here. I may be having problems
>> expressing what is rolling around in my head--its real clear to me ;). 
> 
> :-)
> 
> Hey - I know the feeling. I do think your overlaping meta info and meta 
> data aspects - something that is real easy to do and something that 
> takes a lot of time to seperate. Even Merlin is not perfect here (I can 
> point you to Merlin level meta-info that is actually meta-data-ish). The 
> imprtant things are to seperate "descriptors" from "directives". The 
> "descriptors" define expectations - the directive define the solution. 
> The composition package I've been working on is all about taking 
> descriptors, pulling in directives, and from that building the 
> information model. Is it a source for headaches - sometime yes - 
> sometime no. The more practice the better you get.
> 

Hopefully by starting out with a clean slate I can make it more clear.
First, let me state what I am not addressing:

     I am NOT addressing meta-info or meta-data concerns

Second, let me state what I am addressing:

1) There should be a correlation between namespaces and container extensions
2) A container extension should specify everything it provides
3) A component should be able to declare its dependence on a namespace

So, while the topic I am trying to convey has implications that affect meta-info
or meta-data, I am not trying to specify rules for those concerns.

I am saying that a Container Extension should specify a namespace that uniquely
identifies that concern area.  The Container Extension will look for
meta-information ONLY in that namespace, and it will provide context entries
ONLY in that namespace.  That namespace is the same.

Now, if we identify that as a good thing, we can address entire namespaces/
concerns with one Container Extension.  It also gives us a scalable method
of apportioning the definition of the namespaces/concerns without overloading
the core Avalon namespace.

For example, if I want to dynamically instrument a component, I would have
a set of attributes something like this:

/**
  * @instrument.sample name="Process Transaction Profile" type="time"
  */
public Response process(Transaction trans)
{
     Response response = null;

     // do stuff

     return response;
}

The "instrument" container extension would read and interpret that meta
information.  Also, if there were any context entries associated with
instrumentation, then they would be defined by that same container extension,
and those context entries would begin with "urn:instrument."

So what I am really driving at is agreeing that non-core stuff should be
defined in a unique namespace, and all meta-info and meta-data specific
to that namespace should be provided by the container extension.

I do not want to define what the container extension looks like at this
time, or the mechanisms used to provide the definitions.

-- 

"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


Mime
View raw message