Re: @avalon

On Fri, 21 Mar 2003 01:21, Berin Loritsch wrote:
> The only thing holding up consensus is you.

Same with the marker interfaces we have or will be deprecating. Same with=
 the=20
compatability stuff that is in framework.

> So what would it take to
> change your mind?
>
> I am asking for three standard names:
>
> @avalon.component (in phoenix already)
> @avalon.service   (in phoenix already)

this is used differently in phoenix from the way you proposed. I suggeste=
d=20
that @avalon.role may be a better marker tag.

> @avalon.lifestyle (proposed)
>
> I don't recall us comming to consensus on avalon.component and
> avalon.service and yet you chose to use the avalon namespace.

Lazy consensus. If you have a problem with them then state it.

> So I want to add one more standard name, what's the problem from
> your viewpoint?

I think that the avalon namespace should be restricted to defining resour=
ces=20
that the component requires or provides. lifestyle is not one of those=20
things.=20

Even if it was I don't think it is mature enough to be supported for all =
time.=20
Besides not being able to represent all of the potential lifestyles such =
as=20
"pooled during times X and y, transient other times" or "passivate under=20
condition X"

Hell - I don't even think the lifecycle concept is something we should be=
=20
marking up. I have described quite a few times in the past of a method vi=
a=20
which lifestyle could be broken down into atomic bits of metadata=20

ie

lifecycle=3Dsingle-thread       :=3D ( sharable=3Dtrue,  multiclient=3Dtr=
ue  )
lifecycle=3Dfactory/transient   :=3D ( sharable=3Dfalse, multiclient=3Dfa=
lse )
lifecycle=3Dpoolable            :=3D ( sharable=3Dfalse, multiclient=3Dtr=
ue )

etc.

Then the container can read the metadata about the component and determin=
e how=20
it will be handled. ie A component that is "poolable" can also be treated=
 as=20
"transient/factory" if the container wants without effecting the client c=
ode=20
or component code. It effectively becomes a configuration decision and=20
tunable by the container. Even better it is future compatible.

Anyways if you want to try an develope a set of those then we can try tha=
t=20
(but then again I think they will need time to mature anyways).

--=20
Cheers,

Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham=20