Peter Donald wrote:
> At 04:26 AM 7/4/2002 +0200, you wrote:
>
>>> I have no problem with that - it can't hurt me if it is container
>>> specific. Stephen however wants to force everyone else to adopt his
>>> model.
>>
>>
>>
>> No I don't - all I'm asking for is the hook.
>> What I want is that you add the following operation to
>> ComponentMetaData:
>>
>> /**
>> * Returns the context object for the component.
>> * @param parent the parent context
>> * @return the context object to be supplied
>> */
>> public Context getContext( Context parent )
>> {
>> return context;
>> }
>
>
> * which of course will only be used by Merlin.
No Pete - think about it. CompontMetaData is holding the state
information for parameters and configuration. Different contains can use
services that prepare CompontMetaData and if they access this via
CompontMetaData, then at least we have a common mechanisms for extension
without having different contains narrowing to some specific service
just to get a compliant context.
>
> * which also changes a passive object into an active object
You have repeatedly said that CompontMetaData is extendable. You have
lots of emails on this subject - the reason why, potential approaches,
impact of failing to address this, etc. Could you try to be a little
more constructive - if you don't like it then propose something else
that address the issue. If you don't feel included to put in the time
and effort in that then leave it to others. After all - this is a
collaborative process .... isn't it?
>
> * which could be implemented in Merlin without effecting any of the
> other containers
Pete - for the last time will you please go back and read the email on
this topic. Yes is can be implemented by Merlin. You know very well it
is already implemented by Merlin. Why is it implemented by Merlin -
because Merlin is concerned with generic component deployment - not just
Pete's personal portfolio of interest. I want Cocoon components to run
in Merlin, I want Merlin components to in Phoenix - your position will
ensure that this never happens without the existence of container
adapters in every container - which will not happen - which means no
portability.
>
>
>>> The problem is Stephen wants add it to ComponentMetaData and thus
>>> force all containers to use a single method for constructing context
>>> - despite the fact that this wont work in any existing container
>>> except Merlin .... hmmm.
>>
>>
>>
>> NO NO NO &%#####**!�$%^&
>>
>> I would like to see different containers using containerkit. I would
>> prefer that the center of interoperability is based on containerkit.
>> I've provided several examples of why containerkit breaks this for
>> existing components and goes against the general component model as
>> documeted. I've provided info on how an implementation can address
>> this in response to your claims that it is impossible. I've put up
>> with being accused of of having an IQ in the single digit range,
>> accused of strange and amazing anti-component practices, I'm now
>> accused of attempting to force a solution! Please keep in mind that
>> your objection to the original proposal of a accessor to context was
>> on the grounds that (a) it was exclusively a container concern,
>> following which you raised the assertion was made that it was
>> impossible anyway (leading to a lot of explanitory emails explaining
>> how it is possible).
>
>
> Containerkit is about consolidating practices in containerkit. What
> you propose is not common through containers, and can be implemented
> fine in any particular container. You notice there is also no
> ConfigurationSchema/ParametersSchema or LoggerMetaData or anything
> like that.
Come on - try a little harder. Configuration and Parameters don't have
an explicit ContextDescriptor that declares constraints. Please - if
you going to be difficult then at least put the time and effort into
addressing the issue. You are sating that as far a potable container is
concerned - context is out of bounds. and yet you include a context
constraint criteria. You then argue that the context constraint
criteria is great (because you are the author) - and then you object to
any possibility of a container neutral approach to a mechanisms to meet
that criteria.
You justify this bizarre idea on the grounds of personal attacks,
technical impossibilities, false assertions of forced conditions on
implementation, and now it gets even worse - your proposing that
containerkit is reflecting a recommended practice of neglecting existing
implementations and users and ignoring what exists in the framework
today. I really don't want bother with it any more - you have decided
that this is not an issue and it does not matter when anyone says. You
will not even bother to even try to understand the issue -- all it means
is that containerkit is NOT a portability platform - its Pete's
architectural masturbation which at the end of the day may be the
abstract foundation to something else that delivers the real solution.
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]>
