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...@apache.org> on 2003/07/22 18:51:57 UTC
Context Entries
Since we are well underway with the AMTAGS proposal, I wanted to start my
thoughts on context entries. Currently we have two basic approaches for
context keys:
* Using URNs
* Using opaque strings
Truth be told, there is no real advantage to using one over the other from
a purely technical standpoint. The only tangible advantage comes from the
management perspective. In fact, the URN makes for much easier scoping of
context entries. A Universal Resource Name helps us understand that the
resource belongs to a namespace, and has a unique name within that namespace.
Whether that resource lives locally on the hard drive or on a remote server
does not matter, we can use the same name to access it. That is its strength.
A Resource has specific properties. A resource accessible from a specific
name will always be the same exact resource. That means if the resource is
text, the return value will be text. If the resource is a URL, the value
will always be a URL when accessed by that name. We can use two URNs to
refer to the same logical thing, but if the logical thing is represented
differently, they are separate resources. For example, a File representing
the application home directory and a URL representing the same thing are
distinct resources.
That said, I like the strength of URNs for management purposes. I think that
Merlin is on the right track with using URNs internally. I believe that the
@avalon.entry tag provides for the use of an alias, much the same way as
the @avalon.dependency does the same thing when we refer to a type.
A URN is composed of three elements:
* The text "urn:" which identifies a string as a URN.
* The namespace which precedes the following ":" and comes after the above text
* The actual name of the resource
Examples would be:
urn:avalon:name -- Avalon component name
urn:application:home/file -- Application home as a File
I think we need to be very strict on what we allow in a URN namespace. For
example things that help components with management such as the component
name or logger category can go in the Avalon namespace. All other things like
application home/partition home/etc. should go in their own namespaces. That
way we can specify them as we specify namespaces. I believe this approach will
provide the most flexible and sustainable method of managing the context
functionality of Avalon.
In fact we can identify this as an area that we need to provide for with
container extensions. A container extension needs to provide the context
entries that it provides from its namespace. If the context entry is not
volatile, then its value should be able to be overridden in the assembly
stage--but that is a matter for another discussion.
I also think that by employing this general solution, we can avoid a bunch
of unnecessary conflict between those trying to keep the Avalon namespace
small and those trying to enable a set of functionality.
Phoenix and Fortress need to reconcile their commonalities and possibly
define some context entries for the application namespace. That way we
can specify common namespaces for extensions like the "lifecycle" extension
or the "management" extension.
Does this proposal make sense, and be easy enough to implement?
--
"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
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote, On 24/07/2003 15.11:
>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>> Just as a matter of curiosity, whom are you representing under the
>>>> term *we*?
>>>
>>>
>>> The Avalon team as a whole.
>>
>>
>> And just so I understand, where does this authority to represent the
>> interests and opinions of the Avalon team as a whole come from?
>
>
> Steve, give us a break, will you? >:-|
Sorry - a break from what?
> If others disagree, they will say so. If not, Berin effectively
> represents us, as he is summarising what we have said in all previous
> discussions.
Umm, I'm a little confused - perhaps you can help me out.
Berin is the current Chair of the PMC - in that position he may present
information to the Apache Board reflecting the decisions reached by the
PMC and this community through a process of voting on motions that are
raised. Outside of this administrative function, Berin is a committer
like you and I. In that capacity he does not have the right to assert
the position of the Avalon community without such a vote backing that
position. As far as I recall there has not been a vote on the subject
of the release of the Merlin platform. As such I'm just a tad confused
as to where this new-found authority comes from.
> Till you keep this infantile confrontational attitude, it's
> *impossible* to work with you, hence I suggest Berin to stop this
> discussion altogether till your mails will become reasonable again and
> concentrate the energy in better ways.
As far as attitude is concerned, I though I was being "inquisitive" ...
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote, On 24/07/2003 15.11:
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>> Just as a matter of curiosity, whom are you representing under the
>>> term *we*?
>>
>> The Avalon team as a whole.
>
> And just so I understand, where does this authority to represent the
> interests and opinions of the Avalon team as a whole come from?
Steve, give us a break, will you? >:-|
If others disagree, they will say so. If not, Berin effectively
represents us, as he is summarising what we have said in all previous
discussions.
Till you keep this infantile confrontational attitude, it's *impossible*
to work with you, hence I suggest Berin to stop this discussion
altogether till your mails will become reasonable again and concentrate
the energy in better ways.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Policies and Procedures Refresher (was: RE: Context Entries)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> I was totally unaware of the "benevolent dictator"
> thing - it certainly wasn't included in the wording of neither
> motion nor adopted procedures.
Greg Stein:
http://marc.theaimsgroup.com/?l=avalon-dev&m=104285006706268&w=2
There is no fallback. The PMC Chair is an officer of the
corporation. The
PMC is a group of people to assist in the work of the ASF, nominally
under
the direction of the Chair. If the PMC (and more precisely, the
Chair)
makes a decision, then it is DONE. The Chair has full authority to
act on
behalf of the ASF within the guidelines that the Board has provided
to
that person.
If the Chair does something, then it sticks. There are only two ways
"out": one is if it can be shown they are not acting within the
capacity
the Board outlined for that officer. For example, the Chair goes and
deletes the jakarta-commons archive. That is out of scope. Deleting
the
avalon archive? In scope. Bad, but in scope.
This is from the thread where we (and that includes you) discussed the
Policies and Procedures document.
The fact that the chair is a benevolent dictator has since been posted
numerous times on the PMC list.
To clarify and summarize: The Chair can do as it pleases.
Regarding the rest of your email, we'll take that at a later time.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>>>>Just as a matter of curiosity, whom are you representing under the
>>>>term *we*?
>>>>
>>>>
>>>The Avalon team as a whole.
>>>
>>>
>>And just so I understand, where does this authority to represent the
>>interests and opinions of the Avalon team as a whole come from?
>>
>>
>
>The vote that made Berin Chair. He's not "just a committer", although it
>is in line with most leadership training to act as if it were that way.
>
I view things a little differently - Berin is just a committer (you you
or I) but has been landed with the unfortunate overhead of having to
prepare reports for the Apache Board so that the lads at the top know
what the kids on the street are getting up to. Its not about leadership
- its about upstream reporting.
>Remember that the Chair is a "benevolent dictator"?
>
>
I dreadfully sorry - it seems that I may have been completely mistaken.
I thought that the PMC Chair was elected with the job of representing
this community to the Apache Board based on the decisions of this
community. I was totally unaware of the "benevolent dictator" thing - it
certainly wasn't included in the wording of neither motion nor adopted
procedures. If there is something that actually gives the chair the
right to act in manner outside of or in contradiction with the decisions
of the community then please could you post the details to list? I’m
sure others would be interested in reading this.
>But that's not how it is being used now. The line that started it was:
>
>
>
>>No it isn't. If you recall I had two objections before we could
>>release Merlin.
>>
>>
>
>OK, so Berin has two objections before he thinks it is OK for the Avalon
>Community to release Merlin.
>
Your interpretation clarifies a lot of things. Perhaps we could apply a
little more manipulation and end up with something like this:
"No it isn't. If you recall I had two objections
before [I would endorse a community vote to release
Merlin]."
Now that would eliminate the pretension of preemptive representation.
>I see nothing that implies a position of
>authority here that is above the authority of a committer.
>
>
I agree - your modifed version correctly repositions the statement as a
personal observation.
>As committers we *are* responsible for releases.
>
Correct.
>This is both a moral
>and a legal thing. If a committer thinks that he can't sign off on a
>release (which he is responsible for due to being committer) then he
>has all the right in the world to raise the issues that prevents a sign-
>off.
>
Correct - as far as that individual committer is concerned. But that
does not imply that an individuals opinion is in any way representative
of the community. That's what votes are for.
>Get those two issues on the table (they already are) and get on with
>solving them.
>
>
This presupposes that they are in fact issues. One so-called issue is in
fact an issue with the AMTAGS spec which is in the process of being
addressed. The other so-called issue is an issue from the personal point
of view of Berin and conflicts with what I consider to be a more
pragmatic and user driven position that I have put forward and that has
received positive support from other committers.
As such, one of these is a topic related to development of the AMTAGS
spec - the other is a subject under discussion.
>Frankly, unless issues with Merlin can be solved in a civil manner
>(and at the moment that appears to be too much to ask), I see no
>reason to release Merlin as an Avalon product, as it is clear that
>Merlin and its author isn't part of the Avalon community other than
>in a very formal way (it is hosted on Apache servers and you have
>committ privs).
>
>
Well, I sorry you feel that way - but don't worry, I'm sure you'll feel
better in morning.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Context Entries
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> >> Just as a matter of curiosity, whom are you representing under the
> >> term *we*?
> >
> > The Avalon team as a whole.
>
> And just so I understand, where does this authority to represent the
> interests and opinions of the Avalon team as a whole come from?
The vote that made Berin Chair. He's not "just a committer", although it
is in line with most leadership training to act as if it were that way.
Remember that the Chair is a "benevolent dictator"?
But that's not how it is being used now. The line that started it was:
> No it isn't. If you recall I had two objections before we could
> release Merlin.
OK, so Berin has two objections before he thinks it is OK for the Avalon
Community to release Merlin. I see nothing that implies a position of
authority here that is above the authority of a committer.
As committers we *are* responsible for releases. This is both a moral
and a legal thing. If a committer thinks that he can't sign off on a
release (which he is responsible for due to being committer) then he
has all the right in the world to raise the issues that prevents a sign-
off.
Get those two issues on the table (they already are) and get on with
solving them.
Frankly, unless issues with Merlin can be solved in a civil manner
(and at the moment that appears to be too much to ask), I see no
reason to release Merlin as an Avalon product, as it is clear that
Merlin and its author isn't part of the Avalon community other than
in a very formal way (it is hosted on Apache servers and you have
committ privs).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> Just as a matter of curiosity, whom are you representing under the
>> term *we*?
>
>
> The Avalon team as a whole.
And just so I understand, where does this authority to represent the
interests and opinions of the Avalon team as a whole come from?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Just as a matter of curiosity, whom are you representing under the term
> *we*?
The Avalon team as a whole.
--
"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
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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.
Just as a matter of curiosity, whom are you representing under the term
*we*?
> 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.
The point is that meta-info is about declaring the criteria. Your train
of thought seems to be focussed on a context handling approach which can
be dealt with on the container side in a standard or non-standard
fashion without any implications concerning namespaces at the meta-info
level. The namespace is a mechanism we can use on the implementation
side of the equation to provide interesting solutions to how we deliver
well-managed context.
If I understand what is written between the lines - you not keen on
seeing a standard set of Avalon scoped context entries because this
could be handled by a namespace linked context management subsystem -
the benefits being that the Avalon namespace does not get polluted with
unnecessary stuff. I don't have any problem with a generic namespace
base context management model - in fact its something I've been thinking
about for a while - but I do have a problem with attempting to define
this now on the grounds that this will simplify the Avalon namespace
question. This is backed by the fact that Phoenix and Merlin have near
identical requirements for common set of five context entry keys. Think
of these as the bootstrap set of keys - defined specifically to make
life easier for container users.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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
Which is itself problematic ;-)
>
>
> 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.
>
> 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.
>
> 3) A component should be able to declare its dependence on a namespace
-1
NO
BAD
WICKED
EVIL
:-)
>
>
> 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.
>
>
> 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.
>
> 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.
Problem is that the IF in your question above is a huge if.
>
> 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;
> }
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.
>
>
> 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."
> 0
> 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.
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.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: Context Entries
Posted by Niclas Hedhman <ni...@hedhman.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>> With the *.home.dir and *.temp.dir, not all environments map well to
>> the way it is currently defined. The prime example is the *.home.dir
>> and the Servlet environment. With servlets, the resources are supposed
>> to be accessed via URL--because there is no guarantee that the
>> resource is not part of a packed WAR file. There is a workaround--but
>> it is not required for all servlet engines to allow for it (the
>> findRealPath method in the ServletContext). Other times it is just
>> simply the fact that the container
>> is ultra-simple and does not offer access to the filesystem (which may
>> be a requirement for sandboxed components).
>
>
> I understand - but this is mixture of (a) a component declaring that it
> needs a working directory(e.g. James) and (b) the ability of a
> containment system to meet that contract. If a containment system cannot
> provide a working directory then it has to "not-deploy" the component.
> I'm not saying that a containment system *must* provide a solution to
> the value, I am saying that if we are discussing home or temporary
> directories - then we use the same context keys across all containers.
Since I write a fair amount of J2ME apps, I have come to uise some tricks
to make the J2SE apps more J2ME port-friendly.
One of these issues revolves around the use of files and directories in
J2SE which my J2ME environment doesn't support.
I use an interface expressing the need, a wrapper implementation for each
of the two main environments and a "storage" class supplied by the J2ME
vendor for the J2ME environment (and standard File, FileXXStream in J2SE).
I think this approach is suitable for this case as well;
public interface WritableStorage extends ReadableStorage
{
OutputStream openForWrite( String name ) throws IOException;
OutputStream openForAppend( String name ) throws IOException;
}
And if the "urn:avalong:home.dir" returns a WritableStorage object
instead, the container has a lot of options on how to support (or not)
that, such as sandboxing, specialized storage (possibly remote), and so
on.
Adding my 0.02 ringgit to a very academic discussion, that is not easy to
follow, but sure the end result will be good.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>
>>> I think we need to be very strict on what we allow in a URN
>>> namespace. For
>>> example things that help components with management such as the
>>> component
>>> name or logger category can go in the Avalon namespace. All other
>>> things like
>>> application home/partition home/etc. should go in their own namespaces.
>>
>>
>>
>> I think this is not address the actual needs that are already
>> identified. If we consider the James project, they has gone though a
>> process of abstracting out context entry key lookups to a separate
>> utility class as part of the process of establishing container
>> neutrality. This extra code exist because we have not defining the
>> very basic set of common context entries. I think this is well
>> overdue. Getting in place a common core set of entries is real easy
>> to do. I've already proposed the following:
>>
>> urn:avalon.name
>> urn:avalon.partition.name
>> urn.avalon.home.dir
>> urn:avalon.temp.dir
>> urn:avalon.classloader
>>
>> Are there really any problems mapping the above into any avalon
>> container? I don’t think. I do know that the benefit to the end user
>> will be immediate and tangible.
>
>
> There will never be a problem with urn:avalon.name or
> urn:avalon.classloader.
> As to urn:avalon.partition.name, what does that map to if the container
> does not support partitions?
In Phoenix this equates directly with the app.name in BlockContext
(because in Phoenix there is implicity one partition per application).
In Fortress I would image that this woudl equate to the path of
container heirachies (as it does in Merlin).
>
>
> With the *.home.dir and *.temp.dir, not all environments map well to
> the way it is currently defined. The prime example is the *.home.dir and
> the Servlet environment. With servlets, the resources are supposed to be
> accessed via URL--because there is no guarantee that the resource is not
> part of a packed WAR file. There is a workaround--but it is not required
> for all servlet engines to allow for it (the findRealPath method in the
> ServletContext). Other times it is just simply the fact that the
> container
> is ultra-simple and does not offer access to the filesystem (which may
> be a requirement for sandboxed components).
I understand - but this is mixture of (a) a component declaring that it
needs a working directory(e.g. James) and (b) the ability of a
containment system to meet that contract. If a containment system cannot
provide a working directory then it has to "not-deploy" the component.
I'm not saying that a containment system *must* provide a solution to
the value, I am saying that if we are discussing home or temporary
directories - then we use the same context keys across all containers.
If this means that running the James mail server inside a servlet result
in a deployment failure - then we have suceeded. The container has
correctly signalled its inability to meet a deployment constraint (the
purpose of meta-info). More importantly, this has occured in a way that
is consitent across all containers.
>
>
>>> That
>>> way we can specify them as we specify namespaces. I believe this
>>> approach will
>>> provide the most flexible and sustainable method of managing the
>>> context
>>> functionality of Avalon.
>>
>>
>> The need for a core set of common context entries remains. Simply
>> stating what the keys are that can be used consistently across
>> containers does not conflict with different context management
>> solutions provided by different containers. What is does do is set a
>> minimal level of utility for a portable Avalon contextulizable
>> interface.
>
>
> I understand that we still need a common set of context entries, but by
> using a namespace based approach, we can properly verify wether the
> container implements that set. The core entries that are component
> specific
> will always be available, but other entries may only be necessary in some
> environments. We can say that we support a set (a namespace) of entries,
> and the container can easily validate that the set is implemented.
This can all be handled in the meta-data layer. The mata-data can
establish the set of directives that dive a container the ability to
handle something like urn:steve:more-magic. The meta-info side of the
equation remains unchanged. Once we sort out meta-info, the subject of
meta-data will drop onto the table - and its a much richer subject. Its
where these sort of things are addressed - the solution to meta-info
criteria.
Take a look at the context.xml file in the composition package test
cases (test/conf/context.xml) and the corresponding context test case.
This is all about context management strategies. I think you will good
idea of what sort of things could be possible - and why this isn't an
issue at the meta-info layer.
>
>>> In fact we can identify this as an area that we need to provide for
>>> with
>>> container extensions. A container extension needs to provide the
>>> context
>>> entries that it provides from its namespace.
>>
>>
>>
>> The existing spec for @avalon.context provides support for the
>> declaration of context entry requirements independently of a
>> containers context management solution. I don't definitely don’t
>> think we should move this into the notion of extension - its well
>> defined - meets immediate requirements - and is part of the core
>> Avalon model.
>
>
> All I am saying is that by allowing it to be defined in a container
> extension
> (not the only method, but one of them), all containers can easily
> comply with
> the requirements for that extension. We don't have to manage a set of
> context
> entries separately from that. I imagine in most cases the only time a
> container
> extension would have to mess with context entries is to manage the
> lifecycle
> extensions.
Again - I encourage you to look at the composition package test cases.
You will see meta info that references context entries under namespaces
that are completely foreign to the container, and the role of meta data
is resolving this differential.
>
>
>>> I also think that by employing this general solution, we can avoid a
>>> bunch
>>> of unnecessary conflict between those trying to keep the Avalon
>>> namespace
>>> small and those trying to enable a set of functionality.
>>
>>
>> Can you qualify this a bit more - I got the impression your hinting
>> at something but I don’t know exactly what you’re hinting at.
>> Personally I can't think of anything I would want to modify in the
>> current @avalon.context and @avalon.type (and corresponding XML)
>> relative to the existing implementation. Do you see any issues?
>
>
> Ok. I am not looking at the meta-info at all in this thread. I am
> strictly
> speaking of the org.apache.avalon.framework.context.Context object
> passed in
> to the component. I think the standard tags for context validation should
> stand, and still apply. I am not looking to change them.
Good!
>
> What I am looking at is providing room for the "Container Extension"
> concept
> by declaring a set namespace for a whole set of functionality. It is
> using the
> Container Extention to address an entire concern area. The container
> extension
> would specify everything it provides in its meta information/data--a
> topic
> that can be explored later on.
This is a meta-data concern - not meta-info - but you sadi earlier that
this email is not about the meta-info aspect - so now I'm confussed with
respect to context of this email. If we are discussing container
extension then we are either talking about meta-info or meta-data. If
its meta-info we have everything we need. If its meta-data then its
something we can sort out later - yes?
>
>
> The core thing I am hinting at is that a namespace when it is used in an
> Avalon component refers to a concern area. For example, we may want to
> dynamically instrument components with measurements like accesses/sec or
> average time for a method to run. This concern area would be addressed
> by the hypothetical concern namespace "instrument". All meta information
> and context entries that are specific to the "instrument" namespace would
> be encapsulated in the container extension that supplies that concern
> area.
Declared in meta-data - the directives that fullfill the contraints
expressed in meta-info.
>
>
> Using this approach, the container extensions provide a standard way for
> the container to ensure that the components comply with the requirements
> for the extension.
Yep - in meta-data, not meta-info.
>
>> Keep in mind that I think that an abstract extension framework at
>> this stage is premature.
>
>
> Understood. We can lay down general concepts however that lay the
> foundation.
> We have identifies a number of concern areas that would best fit into the
> container extension concept:
>
> * Instrumentation
> * Management Extensions
> * Remoting
>
> (that's just the short list).
>
> So I am keeping these things in mind, trying to simplify the core avalon
> namespace so that a container that does not choose to support container
> extensions can do the following:
>
> 1) detect if the extension is required
> 2) fail early if the component cannot be run without extensions
> 3) work with all the components in avalon-component
>
>
>>> Does this proposal make sense, and be easy enough to implement?
>>
>>
>> Not really - I think its makes things unnecessarily complex. We have
>> a simple system that works well I think we should focus on closing
>> the configuration schema declaration as part of the type definition -
>> finalize the attribute spec details - and that's it. W can safely
>> evolve the meta-info platform because it’s based on a version schema
>> identifier. I really think we should keep things as simple as
>> possible - get things in place across containers - go though a
>> learning curve - and with experience come back to the entire subject
>> of meta-info extension.
>
>
> 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.
Cheers, Steve.
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Context Entries
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>> I think we need to be very strict on what we allow in a URN namespace.
>> For
>> example things that help components with management such as the component
>> name or logger category can go in the Avalon namespace. All other
>> things like
>> application home/partition home/etc. should go in their own namespaces.
>
>
> I think this is not address the actual needs that are already
> identified. If we consider the James project, they has gone though a
> process of abstracting out context entry key lookups to a separate
> utility class as part of the process of establishing container
> neutrality. This extra code exist because we have not defining the very
> basic set of common context entries. I think this is well overdue.
> Getting in place a common core set of entries is real easy to do. I've
> already proposed the following:
>
> urn:avalon.name
> urn:avalon.partition.name
> urn.avalon.home.dir
> urn:avalon.temp.dir
> urn:avalon.classloader
>
> Are there really any problems mapping the above into any avalon
> container? I don’t think. I do know that the benefit to the end user
> will be immediate and tangible.
There will never be a problem with urn:avalon.name or urn:avalon.classloader.
As to urn:avalon.partition.name, what does that map to if the container
does not support partitions?
With the *.home.dir and *.temp.dir, not all environments map well to
the way it is currently defined. The prime example is the *.home.dir and
the Servlet environment. With servlets, the resources are supposed to be
accessed via URL--because there is no guarantee that the resource is not
part of a packed WAR file. There is a workaround--but it is not required
for all servlet engines to allow for it (the findRealPath method in the
ServletContext). Other times it is just simply the fact that the container
is ultra-simple and does not offer access to the filesystem (which may
be a requirement for sandboxed components).
>> That
>> way we can specify them as we specify namespaces. I believe this
>> approach will
>> provide the most flexible and sustainable method of managing the context
>> functionality of Avalon.
>
> The need for a core set of common context entries remains. Simply
> stating what the keys are that can be used consistently across
> containers does not conflict with different context management solutions
> provided by different containers. What is does do is set a minimal level
> of utility for a portable Avalon contextulizable interface.
I understand that we still need a common set of context entries, but by
using a namespace based approach, we can properly verify wether the
container implements that set. The core entries that are component specific
will always be available, but other entries may only be necessary in some
environments. We can say that we support a set (a namespace) of entries,
and the container can easily validate that the set is implemented.
>>
>> In fact we can identify this as an area that we need to provide for with
>> container extensions. A container extension needs to provide the context
>> entries that it provides from its namespace.
>
>
> The existing spec for @avalon.context provides support for the
> declaration of context entry requirements independently of a containers
> context management solution. I don't definitely don’t think we should
> move this into the notion of extension - its well defined - meets
> immediate requirements - and is part of the core Avalon model.
All I am saying is that by allowing it to be defined in a container extension
(not the only method, but one of them), all containers can easily comply with
the requirements for that extension. We don't have to manage a set of context
entries separately from that. I imagine in most cases the only time a container
extension would have to mess with context entries is to manage the lifecycle
extensions.
>> I also think that by employing this general solution, we can avoid a
>> bunch
>> of unnecessary conflict between those trying to keep the Avalon namespace
>> small and those trying to enable a set of functionality.
>
> Can you qualify this a bit more - I got the impression your hinting at
> something but I don’t know exactly what you’re hinting at. Personally I
> can't think of anything I would want to modify in the current
> @avalon.context and @avalon.type (and corresponding XML) relative to the
> existing implementation. Do you see any issues?
Ok. I am not looking at the meta-info at all in this thread. I am strictly
speaking of the org.apache.avalon.framework.context.Context object passed in
to the component. I think the standard tags for context validation should
stand, and still apply. I am not looking to change them.
What I am looking at is providing room for the "Container Extension" concept
by declaring a set namespace for a whole set of functionality. It is using the
Container Extention to address an entire concern area. The container extension
would specify everything it provides in its meta information/data--a topic
that can be explored later on.
The core thing I am hinting at is that a namespace when it is used in an
Avalon component refers to a concern area. For example, we may want to
dynamically instrument components with measurements like accesses/sec or
average time for a method to run. This concern area would be addressed
by the hypothetical concern namespace "instrument". All meta information
and context entries that are specific to the "instrument" namespace would
be encapsulated in the container extension that supplies that concern area.
Using this approach, the container extensions provide a standard way for
the container to ensure that the components comply with the requirements
for the extension.
> Keep in mind that I think that an abstract extension framework at this
> stage is premature.
Understood. We can lay down general concepts however that lay the foundation.
We have identifies a number of concern areas that would best fit into the
container extension concept:
* Instrumentation
* Management Extensions
* Remoting
(that's just the short list).
So I am keeping these things in mind, trying to simplify the core avalon
namespace so that a container that does not choose to support container
extensions can do the following:
1) detect if the extension is required
2) fail early if the component cannot be run without extensions
3) work with all the components in avalon-component
>> Does this proposal make sense, and be easy enough to implement?
>
> Not really - I think its makes things unnecessarily complex. We have a
> simple system that works well I think we should focus on closing the
> configuration schema declaration as part of the type definition -
> finalize the attribute spec details - and that's it. W can safely evolve
> the meta-info platform because it’s based on a version schema
> identifier. I really think we should keep things as simple as possible -
> get things in place across containers - go though a learning curve - and
> with experience come back to the entire subject of meta-info extension.
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 ;).
--
"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
Re: Context Entries
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Since we are well underway with the AMTAGS proposal, I wanted to start my
> thoughts on context entries. Currently we have two basic approaches for
> context keys:
>
> * Using URNs
> * Using opaque strings
>
> Truth be told, there is no real advantage to using one over the other
> from
> a purely technical standpoint. The only tangible advantage comes from the
> management perspective. In fact, the URN makes for much easier scoping of
> context entries. A Universal Resource Name helps us understand that the
> resource belongs to a namespace, and has a unique name within that
> namespace.
> Whether that resource lives locally on the hard drive or on a remote
> server
> does not matter, we can use the same name to access it. That is its
> strength.
>
> A Resource has specific properties. A resource accessible from a specific
> name will always be the same exact resource. That means if the
> resource is
> text, the return value will be text. If the resource is a URL, the value
> will always be a URL when accessed by that name. We can use two URNs to
> refer to the same logical thing, but if the logical thing is represented
> differently, they are separate resources. For example, a File
> representing
> the application home directory and a URL representing the same thing are
> distinct resources.
>
> That said, I like the strength of URNs for management purposes. I
> think that
> Merlin is on the right track with using URNs internally. I believe
> that the
> @avalon.entry tag provides for the use of an alias, much the same way as
> the @avalon.dependency does the same thing when we refer to a type.
>
> A URN is composed of three elements:
>
> * The text "urn:" which identifies a string as a URN.
> * The namespace which precedes the following ":" and comes after the
> above text
> * The actual name of the resource
>
> Examples would be:
>
> urn:avalon:name -- Avalon component name
> urn:application:home/file -- Application home as a File
>
> I think we need to be very strict on what we allow in a URN namespace.
> For
> example things that help components with management such as the component
> name or logger category can go in the Avalon namespace. All other
> things like
> application home/partition home/etc. should go in their own namespaces.
I think this is not address the actual needs that are already
identified. If we consider the James project, they has gone though a
process of abstracting out context entry key lookups to a separate
utility class as part of the process of establishing container
neutrality. This extra code exist because we have not defining the very
basic set of common context entries. I think this is well overdue.
Getting in place a common core set of entries is real easy to do. I've
already proposed the following:
urn:avalon.name
urn:avalon.partition.name
urn.avalon.home.dir
urn:avalon.temp.dir
urn:avalon.classloader
Are there really any problems mapping the above into any avalon
container? I don’t think. I do know that the benefit to the end user
will be immediate and tangible.
> That
> way we can specify them as we specify namespaces. I believe this
> approach will
> provide the most flexible and sustainable method of managing the context
> functionality of Avalon.
The need for a core set of common context entries remains. Simply
stating what the keys are that can be used consistently across
containers does not conflict with different context management solutions
provided by different containers. What is does do is set a minimal level
of utility for a portable Avalon contextulizable interface.
>
> In fact we can identify this as an area that we need to provide for with
> container extensions. A container extension needs to provide the context
> entries that it provides from its namespace.
The existing spec for @avalon.context provides support for the
declaration of context entry requirements independently of a containers
context management solution. I don't definitely don’t think we should
move this into the notion of extension - its well defined - meets
immediate requirements - and is part of the core Avalon model.
> If the context entry is not
> volatile, then its value should be able to be overridden in the assembly
> stage--but that is a matter for another discussion.
It’s a container problem - all the meta-info has to do is declare the
constraint. Meta-data (out of scope for the moment) deals with the
problem of building/declaring how to create special context content.
>
> I also think that by employing this general solution, we can avoid a
> bunch
> of unnecessary conflict between those trying to keep the Avalon namespace
> small and those trying to enable a set of functionality.
Can you qualify this a bit more - I got the impression your hinting at
something but I don’t know exactly what you’re hinting at. Personally I
can't think of anything I would want to modify in the current
@avalon.context and @avalon.type (and corresponding XML) relative to the
existing implementation. Do you see any issues?
>
> Phoenix and Fortress need to reconcile their commonalities and possibly
> define some context entries for the application namespace. That way we
> can specify common namespaces for extensions like the "lifecycle"
> extension
> or the "management" extension.
Keep in mind that I think that an abstract extension framework at this
stage is premature.
>
> Does this proposal make sense, and be easy enough to implement?
Not really - I think its makes things unnecessarily complex. We have a
simple system that works well I think we should focus on closing the
configuration schema declaration as part of the type definition -
finalize the attribute spec details - and that's it. W can safely evolve
the meta-info platform because it’s based on a version schema
identifier. I really think we should keep things as simple as possible -
get things in place across containers - go though a learning curve - and
with experience come back to the entire subject of meta-info extension.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org