Nicola, >> I'd like to know one other thing. Somthing I thank may be part of >> the bad karma here, have significant changes been submitted prior to >> a decent discussion and a vote. > > > This was hard to do. > You can see that Fortress and Merlin are merging, due also to good > communication. > But communication is a two way thing... you can't open the door from > the outside... > >> If yes, then we have a real simple way of ensuring accord in the >> future.... > > > Getting people to discuss more extensively instead of vetoing with > laconic statements? > Getting people to participate to other containers? > > Peter Donald wrote: > "No you summed it up well. All the containers I will work on will have > a common model. > " > > *I* will work on? > Shouldn't it be "we"?
A small faux pas. > "Currently this is evolving but getting closer to set and is basically > defined in containerkit project. 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. 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. > " > > Ok, I agree. > > Then, since we are *all* of the same idea, let's define and vote this > together. > > Here is my proposed action plan. > > 1) Merlin/Fortress people do not commit code to the Phoenix CVS that > is about Merlin/Fortress stuff. Phoenix is in beta IIRC, and things > are already fixed. Let's get on with a release. > > 2) With the help of Paul Hammant, Peter Royal & friends we start a > *profitable* discussion about what Merlin has to give Avalon, what the > proposed new DTD gives, and get an agreement to a common DTD. > Since we already have now two Containers (Merlin/Fortress in dev and > Phoenix stable) that can use Cornerstone, and since Peter Donald seems > to be going in the same direction of deprecating Blockinfo, we finally > can lay out the one and only Avalon Component Spec. > > 3) We write documentation on how to use Merlin/Fortress in Phoenix. > I want to be able to run a Merlin/Fortress App in Phoenix, and I think > it's really possible. > What the Merlin/Fortress integration is showing is that instead of > three containers we can simply a layered container: Phoenix contains > Merlin contains Fortress. > With Fortress and Merlin there is overlap that is being overcome. > We'd have to do it with Merlin/Phoenix too. A good plan. No, a great plan. It would defuse the situation currently and allow us to push forward with a careful common direction for all containers, but spec first, rather than code. XP allows us to refactor at will. In the idea project, all can change at will as long as it is a step nearer our end goal and that the pair (and by implication the team) agree it is right. By contrast, API developers (is not service/block with its XML an API?) must move more slowly. Speed can be faster if nothing has been released. We all know that is a critisism levelled at all Avalon sub-projects in the past. Anyway, Phoenix being stable (and hopefully going FCS soon) artificially slows down Merlin/Fortress as it has a compatability baseline and a user community. Sad for Fortress/Merlin but true. Just an observation. Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
