mcconnell 2002/12/16 20:47:12
Modified: merlin/src/xdocs faq.xml
Log:
Minor doc updates.
Revision Changes Path
1.2 +2 -2 avalon-sandbox/merlin/src/xdocs/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/avalon-sandbox/merlin/src/xdocs/faq.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- faq.xml 1 Dec 2002 06:43:22 -0000 1.1
+++ faq.xml 17 Dec 2002 04:47:12 -0000 1.2
@@ -21,7 +21,7 @@
<s2 title="What's the difference between Merlin and Phoenix?">
-<p>Merlin and Phoenix can be considered to be derived from the same family in terms
of architecture and notions of "what a component is". Both Merlin and Phoenix
leverage meta-information about a type of component (the .xinfo resource). Meta
information used by Phoenix is described in a <blockinfo> whereas Merlin uses
the more advanced <type> DTD. Plans for Merlin development include addition of
support for the block-info DTD (enabling execution of Phoenix style components inside
Merlin). Both models share many of the same DTD features and it is expected that
Phoenix will migrate to or at least support the <type> schema in the future.
With this in place, Phoenix based components will be interoperable within Merlin
providing the components do not use Phoenix specific interfaces or classes.
Typically, the two aspect to watch for on Phoenix based components that limit
portability are (a) references to the class BlockContext (which can be eliminated by
using the context key instead of Phoenix specific context accessors), and (b), the
usage of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
+<p>Merlin and Phoenix can be considered to be derived from the same family in terms
of architecture and notions of "what a component is". Both Merlin and Phoenix
leverage meta-information about a type of component (the .xinfo resource). Meta
information used by Phoenix is described in a <blockinfo> whereas Merlin uses
the more advanced <type> DTD. Plans for Merlin development include addition of
support for the block-info DTD (enabling execution of Phoenix style components inside
Merlin). Both models share many of the same DTD features and it is expected that
Phoenix will migrate to or at least support the <type> schema in the future.
With this in place, Phoenix based components will be interoperable within Merlin
providing the components do not use Phoenix specific interfaces or classes.
Typically, the two aspect to watch for on Phoenix based components that limit
portability are (a) references to the class org.apache.avalon.phoenix.BlockContext
(which can be eliminated by using the context key instead of Phoenix specific context
accessors), and (b), the usage of the BlockListener and ApplicationListener interfaces
(both representing Phoenix specific extensions).</p>
<p>Aside from these differences, Phoenix and Merlin are very similar - they both
handle service assembly, activation, and decommissioning. Differences appear with
respect to the approaches used and the overhead implied on a user. Merlin makes every
attempt to minimise that level of information required to assemble a service model.
For example, Merlin does not require explicit linking of components under an assembly
file. Furthermore, Merlin provides a framework for defaults management enabling
automatic service establishment. Perhaps most significant is the design objective of
Merlin to provide simple programmatic embedding of kernels and containers into other
components and foreign systems. Relative to Merlin, Phoenix is much more static in
that it requires a significantly higher level of engagement in the establishment of a
service model. On the other-hand, Phoenix contains additional features not present in
Merlin - in particular JMX support.</p>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
