Corey Jewett wrote:
>So the context we are discussing is actually the context of the
>component? Rather than a context being handed to the component, a la
>Contextualizable.contextualize(Context)?
>
>I thought we were discussing the later.
>
We are :-)
A Contextualizable object needs to be supplied with a context. I'm typing to explain
that the context value that is supplied should be comming from a value held in the
ComponentMetaData class, and that sufficient freedom should be enabled for
implementations to ensure that the supplied comext value is consistent with the
ContextDescriptor constraint model.
Cheers, Steve.
>
>Corey
>
>On Wed, 2002-07-03 at 23:18, Stephen McConnell wrote:
>
>
>>Corey Jewett wrote:
>>
>>
>>
>>>Trying to follow what's going on here it seems to me that Stephen wants
>>>an ObjectConfiguration under the name Context.
>>>
>>>
>>>
>>>
>>Nope!
>>
>>What Stephen wants is to provide support for any component consitent
>>with the component model. I'm not concerned with what the component
>>does with infortantion supplied to it.
>>
>>I am concerned about a fault in the containerkit architecture which if
>>not corrected will result in continued non-portability of components.
>>
>>I'll try and explain. I working on a container - basically an
>>application that automates the creation, deployment and decommissioning
>>of one or more components (without concern for an component implementers
>>idea of what is good, bad, appropriate or otherwise). A container that
>>has an objective of running any component has to be able to provide the
>>information that the component declares that it needs. But this
>>requires synchronizing three different viewpoints - the *component*
>>model itself (stable and something that represents a fixed point in this
>>equation), the specifications and implementations of resources through
>>which a component can declare *constraints* (this is the content of the
>>containerkit metainfo model), and thirdly - the *criteria* within a
>>metadata model that is used to describe how information to be passed
>>between a container and a component is created. Typically, the approach
>>to metadata creation is container specific - however, container kit
>>provides some basic structures on which different contains can share
>>common foundations.
>>
>>If your look at the component model in Avalon it is defined though a set
>>of patterns and interfaces. Six of these interface actually declare
>>state that maybe required by a component - these include the LogEnabled,
>>Configurable, Parameterizable, Contextulizable and the
>>Serviceable/Composable interfaces. Of these, the Contextualizable and
>>Serviceable/Composable interfaces present a significantly higher level
>>of container/component interaction than the rest. In the case of the
>>Composable/Serviceable interfaces the metainfo model appears reasonably
>>complete in both metainfo and metadata. The model provides support for
>>declaration of the association of types services that are keyed relative
>>to the container scoped names. The model does not dictate how the
>>associations are derived (that's a container concern). In general is a
>>level of abstraction I'm very comfortable with. However, if we look at
>>the same picture from the point of view of managing Contextualization of
>>a component - the containerkit framework is either (a) incomplete or (b)
>>inconsistent. What we have in containerkit is the full definition of
>>the metainfo (ability to describe the context constraints), but nothing
>>on the metadata side.
>>
>>Some suggestions have been put forward stating that validation of
>>component metadata is impossible. Other information has been provided
>>that shown that this is possible, already available, and has been in use
>>for some time. However, much of the discussion on this thread has
>>focussed on discussing that mechanisms to deal with a broader set of
>>context requirements based on existing and current cases of context
>>usage (which is primary reference point). An important consideration
>>here is that the containerkit framework does not need to include the
>>mechanisms for context directives, directive validation or even creation
>>- all of those things can be handled by a container implementation.
>>
>>The issue is that the current definition of the metadata type that
>>effectively represents the set of information to be used in establishing
>>the state of a component does not include an operation to get the
>>context instance. If you look at the component ComponentMetaData class
>>in containerkit you will find operations enabling access to instances of
>>Parameters, Configuration but nothing for Context.
>>
>>The solution is to add a single method 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;
>> }
>>
>>Simple!
>>
>>But the impact is significant. It means that services that I develop
>>that extend ComponentMetaData can override this method to provide
>>complete support for the standard component model and metainfo
>>constraints. This means I can say to customers that the container I
>>provide is capable of delivering complete support for the component
>>contact. Beyond this, we will be able to deliver a validation tool that
>>checks component integrity - its then the obligation for the container
>>authors to provide nothing less that 100% compliance with a component
>>contract or document non-compliance.
>>
>>One last point - why is this important? If Context is not provided
>>through the ComponentMetaData class, then the ComponentMetaData clas is
>>not a reference point for portability (because container developers will
>>handle the context issue in different ways). This simply means that a
>>lot of potential for component reusability disappears and the value of
>>containerkit diminishes.
>>
>>Hope that clarifies things.
>>
>>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]>
>>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
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]>
