avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Features for next Phoenix Beta.
Date Wed, 14 Aug 2002 15:51:27 GMT


Peter Royal wrote:

>On Wednesday 14 August 2002 07:36 am, Peter Donald wrote:
>  
>
>>On Wed, 14 Aug 2002 21:31, Stephen McConnell wrote:
>>    
>>
>>>     Independently of question concerning meta-models, we must at least
>>>     ensure that Phoenix provides support for Type DTD in order to ensure
>>>     interoperability.
>>>      
>>>
>
>The "Type DTD" you speak of is the forked-containerkit DTD?
>

Corerect.

http://jakarta.apache.org/avalon/type_1_0.dtd

Here is a summary of the differences:

  1.  root element

      in containerkit DTD it is "<component-info> whereas the Type
      DTD uses <type>.  A different root element is useful in
      differentiating containerkit structures form Type structures
      when building the meta-info model (when building the Type meta-
      info there are a couple of extra elements that are handled).

  2.  containerkit declares depedencies and services using a
      <service-ref/> element.  The type DTD uses a <reference/>
      elemement because the Type handles references to services,
      dependencies AND lifecycle extension phase dependecies AND
      lifecycle extension provider statements.

  3.  The type DTD includes the <stages/> elemement which contains the
      set of stage dependecies that a type has on extension providers.
      A container shuch a Phoenix which does not support lifecycle
      extensions should recognize this element and reject the
      component. Also, the type DTD contains am <extensions/> element
      which includes extension provided by a component implementation.
      The same case applies here - Phoenix should reject such a
      component.

Based on tests I've done here, I can do the following within Merlin:

   a. run a phoenix block in Merlin after modifying the .xinfo
      file to follow the Type DTD

   b. run a Phoenix block using blockinfo DTD, providing the
      block does not use Pheoinix specifc APIs (such as
      BlockContext)

   c. run a Phoenix block using the Type DTD and declare a
      alternative BlockContext implementation to bypass those
      frequent Phoenix depedencies that seem to exist in almost all
      Phoenix blocks

It would be reasonably trivial for Phoenix to use the Type Meta-Info
API to build a meta-info model (using the Type API, then extrace from
this the Phoenix structures - alternatively, its really simple to put
in place a xml reader for a particular schema (becauae they are very
similar).

The real issue is that as long as Phoenix contianues with blockinfo,
there is not way another containe can detect block context requirements.
If you tak a look at something like simpleserver - it will fail because
of the block context issue.  This cannot be resolved withou Phoenix
upgrading to a DTD that actually declares context type and context value
keys and types.  If that's containerkit - fine - Merlin already supports
the containerkit DTD.


>>It won't.
>>
>
>Why not? 
>

I was wondering the same thing!

I can assure you that there are no technical reasons why not.  

Perhaps my term "assured interoperability" is being confused with
"asured deployment".  What I mean by interoperability is that if I
take a Merlin or Fortress component that uses the Type DTD, and I
put it inside a Phoenix application context, and if this component
does not use extensions or default configuration then it should run,
otherwise, Phoenix should return a sensible error/warning message
stating that the component cannot be executed due to
"some-intelligent-error-message".

Beyond this simple scenario - it would also me possible to embedd a
Merlin kernel inside Phoenix and Phoenix could automatically delegate
Type based componets to the embeded Merlin Kernel.  Phoenix, after
initializing the kernel could then grab refernence to the services and
use this in the normal Phoenix assembly process.  Even more potentially
useful would be to use the Merlin engine as the assembly engine inside
Phoenix - but this would require that things like block-listener and
other Phoenix specific resources be packaged as extensions and/or classic
components.

>
>
>IIRC, the last major disagreement was over the metainfo for component 
>contexts? Is that still the case? Is that the only obstacle?
>

Using a common DTD does not imply using a common meta-info model.  For
example, Merlin can read in a blockinfo (Phoenix) DTD as the source to
creation of a new Type instance.  It can do the same things with a
containerkit DTD and the Type DTD.  

There is no "meta" issue here.

Cheers, Steve.

 

>
>-pete
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message