Leo Simons wrote:
>On Wed, 2002-08-28 at 09:35, Stephen McConnell wrote:
>
>
>> >> In the list below I don't see why we need component, partition and
>> >> application seperation - these notions are container specific.
>> >
>> >
>> > That 's what I thought, but...
>> >
>> >> I would prefer to the subset :
>> >>
>> >> avalon:home.dir
>> >> avalon.work.dir
>> >> avalon::common.classloader <-- but question on this
>> >> avalon::name
>> >
>> >
>> > The question is: how can we differentiate between component, partition
>> > and application - level - stuff?
>> >
>> > What about:
>> >
>> > avalon:home.dir
>> > avalon.work.dir
>> > avalon:common.classloader
>> > avalon:context:name
>> >
>> > and
>> >
>> > avalon:app.context
>> > avalon:partition.context
>> >
>> > ?
>>
>>
>>The issue is - what does it mean?
>>
>>If we look at the core requirements, what we need are the primitive
>>values that a container must be able to provide to a component.
>>
>>
>
>I think what we need to do first is decide the primitive key names and
>value types a container must use to provide a certain piece of
>information to a component.
>
>For example, if a container has a notion of "home directory" at the
>"application level" and exposes it to components, it should do so by
>providing it to components as an instance of File with the key
>"avalon.application:home.dir" inside the Context passed in.
>
>It is too early to specify the "minimum context". For example, we do
>*not* specify "all containers should provide components with a
>classloader in the context using key "blah"".
>
OK.
>
>> But
>>before doing this we must fully understand what these things mean.
>>
>>The distinction between a component and an application is something that
>>exists as an implementation artifact.
>>
>> * What should containers provide in a situation where we
>> don't have a formal definition of an application.
>>
>>
>
>nothing or a default (more coarse or less coarse as appropriate)
>
>
>
>> * What should a container provide in respect to a partition
>> without a specification of a partition.
>>
>>
>
>nothing or a default (more coarse or less coarse as appropriate)
>
>
>
>>Putting in place specifications of the notions of application and
>>partition go further that the framework specification - as distinct from
>>the home, work and classloader keys which are much operational aspects
>>relative to the framework spec.
>>
>>As more concrete ideas on things like "what is an application" emerge,
>>we can address extensions to a common keys and attributes specification.
>> There is no need to declare them before that.
>>
>>
>
>I think the concepts of application and partition are generally clear
>enough to be part of the specification on this level. I do agree that
>the definition of both in this context (no pun intended) should be part
>of the proposal.
>
Given a structure:
<domain>.<scope>:<key>
Where domain is "avalon", scope something like "common", "application",
"partition", etc. and the key is string following convensions such as
directories container is ".dir" suffix.
Here is a breakdown of different scopes and my understanding of them:
Scope Description
system relative to a single JVM - resolution is
strait forward because thare is only one
system
Example: avalon.system:implementation or
avalon.system: version
application a logical association of a family of
components - multiple application scopes
may exist within a single system and values
assigned to keys within this scope may
be different from one application to another
Example: avalon.application:home.dir is an
instance of java.io.File created by a container
for a specific instance of an application.
Implications: containers must provide at least
an implicit single application scope.
Implementation may provide support for multiple
application scopes.
container a scope covering a manageble collection of
components
Example: avalon.container:classloader - the
classloader assigned to the container
Implications: containers must provide at least
an implicit single container scope.
Implementation may provide support for multiple
container scopes.
component a scope dealing with information about a specific
instance of a component
Example: avalon.component:name is a name assigned
by the container to the component
partition ?
common ?
I think that there is a difference between application and container
scopes (which is why I have included it above). Application scope is
much more about a familiy of components wheras container scope is about
unit of seperation.
My impression is that the "common" scope is falling out because the list
is looking more complete. The partition scope bothers me because I
don't have any immediate examples of the sort of information that a
component would/could be requesting.
Thoughts?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
