Before we go too far down the holy grail crusader mentalities, lets keep
in mind that neither ContainerKit nor Merlin's Meta Model (which is what
it is) has been voted on or accepted as the standard. Therefore NEITHER
deserve the moniker Avalon Meta Model. That cannot be given until we
have
decided on a standard.
<rant>
The problem with excalibur as it stands is that there are too many forks
of functionally equivalent things. We have a fork of ContainerKit, a
fork
of Merlin, and a fork of the proposed extension mechanism. Forks are
not
evil in and of themselves. The problem occurs when there is no
communication between the original projects and the forked versions.
Also,
the fork needs to answer some need that cannot be answered in the prior
version. Sometimes the need is purely political, but that does not mean
that you can't learn from the original authors. One thing that is
important
with forks is that you should *never* remove the original author tags.
</rant>
Now, as the table that was in another thread showed, the ContainerKit
Meta Model and the Merlin 2 Meta Model are largely equivelant. The
major
distinction is that Merlin has support for Stage and Extension meta
info.
I need some clarification on the Stage meta info--if it is referring to
Stephen's first cut at forking the extension mechanism then it needs to
die. If not, then I need to know what it is talking about.
Either way, it is important to note that *Extensions* are just that--
*Extensions*. Therefore containers are not required to implement them.
However, if they are implemented, they should be implemented in a
consistent
manner. I would be happy with a meta model that validates that the
extension can be satisfied, and if the container does not support the
extension/stages then it needs to fail-fast and tell the developer that
they cannot use that component in the container. The documentation for
extensions must be resilliantly clear that you cannot expect components
that take advantage of extensions to work in absolutely every container.
Generally speaking, if ContainerKit does not provide validation, I would
like to see it do so. I would *really* like to see a merging of Merlin/
ContainerKit meta info. If there are any blockers to that happening
that
are technical in nature (technical, not political) I would like to hear
it. Another thing that would be emensely helpful is a suite of test
cases for both ContainerKit and Merlin that prove their compatibility
and their claims. Merlin has absolutely no testcases which makes me
nervous. I haven't looked at the ContainerKit code, but if it has the
same problem it needs to be rectified.
Lastly, I would like to see the extensions added to ContainerKit and
have them marked clearly that not all containers have to support
extensions, but they have to notify the developer if it detects a
component that requires extensions and the container does not support
them. If ContainerKit has validation in it, then that notification can
be handled by ContainerKit. Optionally, the container or ContainerKit
can issue a warning that the component is using non-standard extensions
if it does support extensions. Would that be satisfactory?
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
