Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>> Less is more.
>>
>> 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 is the primitive
values that a container must be able to provide to a component. 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 defintion of an application.
* What should a container provide in respect to a partion
without a specification of a partion.
Putting in place specifications of the notions of application and
partition go further the framework - as distinct from the home, work and
classloader which are much operation aspects relative to the framework spec.
As more concrete ideas on thins like "what is an apprlication" - we can
address extension of the common atttibutes - there is no need to declare
them at this time.
>
>
>> I've included the avalon:name entry because without it you will not
>> be able to resolve all of the Phoenix portability issues.
>
>
> IIRC it has already been proposed out of a need somewhere, ok.
It is required by several of the cornersotone components due to the
inclusion of the getName operation in BlockContext.
>
>
>> For the home and work values - no problem - for the
>> "common.classloader" - what does this mean - is it different from a
>> regular classloader supplied to the component ?
>
>
> Can be.
If it is the classloader that is supplied to the component then I think
we should drop "common" prex.
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]>
