Peter Donald wrote:
>On Sun, 18 Aug 2002 18:32, Paul Hammant wrote:
>
>
>>> My only rationale explination I can see is that Pete is
>>> simply attempting to oppose anything that would facilitate
>>> component reuse outside of Phoenix. I believe that this an
>>> attitude will simply result in the death of Phoenix. I don't
>>> see that as too great a problem as the Merlin/Fortress work
>>> is in many areas significantly ahead of Phoenix. However,
>>> Pete's continued opposition to an open-container world is
>>> damaging overall Avalon credibility and remains a very real
>>> concern.
>>>
>>>
>>My hope is that Peter is only making sure that the component contract
>>changes are well thought out and carefully planned. I think Peter has
>>no formal objections to other containers that can mount either a)
>>existing blocks or b) entire SAR files. With respect to a) I am
>>guessing Peter believes the contract with the .xinfo files (and .mxinfo
>>for mgmt) is good enough. I am guessing that Peter has no opposition to
>>those other containers not using assembly.xml and config.xml. I'm
>>putting words in Peter's mouth here (my second-guessing gland quite
>>often goes into overdrive), so perhaps Peter can clarify where the
>>differences for alternate container should be apparent.
>>
>>
>
>No you summed it up well. All the containers I will work on will have a common
>model. Currently this is evolving but getting closer to set and is basically
>defined in containerkit project.
>
Umm, sounds familiar - a common model defined within a scope that
enabled YOU personally to veto anything that YOU personally don't like.
Reality check - containerkit doesn't work for Merlin, doesn't work for
Fortress. Do you indent to deal with this or simply discount the rest
of us as irrelevant to you view of the world ?
>It would be great to see other containers
>reusing the shared components and this will happen in time. My initial
>motivation was to enable myrmidon, and cocoon sharing with Phoenix sharing as
>a fringe benefit.
>
>Hence in the future BlockInfo will probably be deprecated and replaced with
>the more comprehensive ComponentInfo.
>
And ignoring the more comprehensive and validated Type DTD.
Come on - lets get down to real tangible content here - your objections
to the Type DTD are that is provides support for something you have been
unable to sucessfully implement with the context of Phoenix.
Independetly of the fact that two other containers have successfully
addressed and resolved this issue - you continue to claim that this
isn't a good thing but neglect to explain why. You still havn't
addressed why Phoenix cannot use a common DTD that includes defintions
that Phoenix currently does not support.
>At that point there will be one
>recomended description format and tools will be made to transform BlockInfo
>files into ComponentInfo files and to make generation of info easy.
>
As opposed to working with the commuity in developing a comprehensive
solution.
You and I both know that you can implement the entire containerkit
meta-info model using the Type DTD. You have not addressed the question
of the common DTD - istead, you have chosen (repeatedly) to respond on
the grounds of a meta-info API conflict which is misleading and
inacurate. An API defines a info model and that model can be created
for different mechanisms. The API is not defined by the DTD. Please -
let's focus on one layer at a time and keep the discussion cleanly
focussed on the issues at hand.
The objective is one DTD that address all of the requirements - not
just yours.
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]>
