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 Wed, 23 Jul 2003 12:57:53 GMT
Stephen McConnell wrote:

>>
>> I am NOT addressing meta-info or meta-data concerns 
> 
> Which is itself problematic ;-)

No it isn't.  If you recall I had two objections before we could release
Merlin.  One was beefing up AMTAGS, and the other has to do with the way
context keys are assigned.  That is what this thread is supposed to be
about.

I am recognizing the URN approach as useful, and I am trying to put together
a solution that I think will help in the long term as well as the short
term regarding HOW it is useful.


>> Second, let me state what I am addressing:
>>
>> 1) There should be a correlation between namespaces and container 
>> extensions 
> 
> Not necessarily - consider the following:
> 
> @avalon.entry key="urn:whoever:whatever" type="org.whoever.Widget"
> 
> The solution to this constraint is constrained by the meta-info 
> declaration but it does not require or impose any constraint on the 
> meta-data used to resolve the constraint. I.e. the declaration of some 
> namespace in meta-info has zero impact on what is possible in meta-data 
> land. If there is no correlation (other than the constraint) we have a 
> classic contract/implementation separation. What I'm trying to say here 
> is that the notion of a shared namespace ties problem to solution – but 
> they are separate concerns - descriptors in meta-info define the problem 
> (constraints) - directive in meta-data define the solution. Problem and 
> solution should not be linked by namespace.

?!?  I don't understand your point.  Furthermore, I think we are starting to
go down a path that will derail any positive part of this discussion, so we'll
try to pull in the rains a bit and focus on commonalities (IOW let's come
back to this later).

>> 2) A container extension should specify everything it provides 
> 
> Define "container extension" in terms of meta-info and meta-data that 
> preserves the seperation of problem/solution and we have a framework for 
> problem identification and solution delivery.
> 
> Without that, the ingredients are missing.

Here is how I see the distinction between Meta Info and Meta Data in Avalon
terms--this is more generic than the way that it is defined within merlin.

Meta Info: Information about a component that is required for management,
            tooling, or verification.

Meta Data: Data about the Meta Information that can provide a larger picture
            of the problem space.

I think what you have defined in the Merlin Meta-Data subproject is more
analogous to _directives_.  I.e. how to dynamically populate default entries
for the context.  Perhaps we could call them Meta-Generators or Meta-Directives?
Either way, I am trying to separate definition (interface)/solution so that
we can enhance the framework at a later time for the unique requirements
of container extensions.

>> 3) A component should be able to declare its dependence on a namespace 
> 
> -1
> NO
> BAD
> WICKED
> EVIL
> :-)

So you are saying that "import" statements are bad, wicked, and evil?

Getting back to the meta-info extensions which we are not going to address
right now, we need a way to signify to the container that the component
expects certain aspects to be parsed.  If the container knows that there
are other namespaces (i.e. like the "instrument" example or even better
the "management" example) that are important, there is a likelihood
that the component will not function properly if the logic to handle that
concern area does not exist.

The container needs to know what and how to address that issue.  However,
since we are most concerned about the pure Avalon space we can address
that later.  The *reason* I want to bring it up now is so that we are aware
that we have an option to define namespaces for concern areas, which will
allow us to define certain concern areas that are not shared accross all
environments and define the context entries in those namespaces.

It is my expectation that in the short term, the context entries will
continue to be defined by the present methods (Fortress assumes the
container is omniscient, Merlin uses the meta-directives, Phoenix is
somewhere in the middle).  The important thing is that the container can
authoritatively say that it can supply the known contracts for the concern
area.

Start thinking about namespaces as interface definitions for concerns that
cannot easily be expressed in code.  For example, the "application" namespace
could define context entries for how to get a work directory or the
application's context directory.  The "partition" namespace would define the
context entries for the same thing.

The Container Extension concept would implement these namespaces in the future,
but in the near term they are addressed the same way.

The concept of namespace in all the languages I know, as well as XML (not a
language) provides a dual purpose:

1) To separate out a set of functionality/interfaces/declarations into a
    logical module--avoiding name conflicts.

2) To allow one module/namespace to use the facilities defined by another
    module/namespace.

In XML it is less clear because the namespace is not required to map to a
schema definition--although in best practices it does.  By declaring that
we are using a namespace (in Java they are packages), we are declaring that
there is a dependency from one namespace on another.  That is another topic
altogether.  However I find that the concept has a real application here.

That is why I want to push as much out of the Avalon namespace as possible.
It makes definition of the Avalon namespace easier, and it helps clarify
the "avalon" interface to the components.


>> 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. 
> 
> 
> The topic you’re trying to address must be expressed in meta-info and/or 
> meta-data. Without this the topic is too abstract to be able to enforce 
> in an interoperable manner.

That is an implementation concern.  I am introducing the topic so that we
can more easily scope what makes it to the Avalon namespace--knowing that
we have the option to define the same thing in another namespace.  We may
already know several needed entries--but that does not mean that they should
be put in the Avalon namespace by default.

We can talk about implementation details in the future.  In the short term,
let's concentrate on the interface.


>> 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.
> 
> See -1 note above.
> These are separate issue - like interface and implementation.

See above response to your -1.

> 
> I understand – your example is clear meta-info extension. You describing 
> a component implementation that is capable of providing instrumentation 
> for a particular profile and type. The Avalon component model knows 
> nothing about instrumentation (today). What I am saying is that this is 
> something we need to deal with *after* we get the basics in place. I 
> fundamentally disagree that there is a namespace correlation because I 
> believe this breaks info/data separation. What I would like to see if 
> people doing stuff with the core model and from that we learn how to 
> address these types of problems. I have a few ideas - but they are ideas 
> that presume a good understanding of the meta info/data separation - and 
> honestly, we (the community) are not there yet.
> 

I am saying that the context entries and meta-info extensions should have
a strong correlation.  They should be part of a namespace which represents
a non-code interface.  We can theorhetically have 100 implementations that
implement that concern area.  I agree that we should worry about the
mechanisms to accomplish this later.  I think now we need to know how to
declare the interface.

> A part of me is violent agreement - and another part of me is in violent 
> opposition. I figure its going to take a while for me to reconcile these 
> two - and I figure that successful and failed experiments by all of us 
> will be an instrumental ingredient to that reconciliation.

Perhaps now that you know that I am only trying to address the interface
side of the equation (i.e. certain context entries are required to implement
this "interface") you can be in violent agreement.  I think the opposition
comes from trying to define implementation details too early.

-- 

"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