All, I have been following the discussions about a single container or a set of containers with some interest. However, reading Peter Donald's emails I believe that the project is doomed to failure due to its structure.
I believe that the need for non-concensus-based development of Phoenix (that is, not concensus across all of Avalon) is (and please correct me if I'm wrong here, Peter) that your user base demand certain development / new features. You state as much when you said that the comments were "easier to sell to the boss", etc. Now, this could be done via concensus across Avalon, which is by necessity a slower process than concensus across Phoenix due to Phoenix being a subset of Avalon. Or, you could solve it with a container-specific extension that would then be promoted to "official" API. The problem: 1) If you choose concensus, you are slowing down development of Phoenix, meaning that your users suffer. Concensus may be fine and all, but it sure doesn't pay any paychecks. 2) If you choose container-specific extensions you end up with: "a reference container with container specific extensions" which sounds like an oxymoron to me. I therefore propose the following: Phoenix drops the "Avalon reference container" part of itself and joins Merlin, Fortress and the others as just another container. Advantages: + You can drive development much faster. + Less coupling between Phoenix and framework. + Forces us to really consider the contracts in framework. Disadvantages: - You lose some advertising points. Invariant: 0 Code sharing, three-tiered container hierarchy and all is still perfectly possible and a separate issue. 0 Phoenix stays as-is, just not being the reference container. Part 2: What is a reference container? With Phoenix as a reference container we ended up with a maxmimalist container that saw wide commercial deployment. For reasons above (*direct* exposure to user requirements), Phoenix evloved much faster than framework, meaning that it is: + A reference container for framework + A set of container-specific extensions + A testbed for expermental code. This is too much. In my opinion, a reference container is what you go look at to get clarification of a contract in framework. Not something you'd deploy commercially. I would propose that the reference container should be very simple, and only evolve as framework evolves. The experimental code, the user feedback, should be at the Phoenix/Fortress/Merlin level. Then, once there are features in those containers that have withstood the tests of real-life deployment, should the features be merged back into framework and the reference container. This allows all sorts of experiments at the Phoenix/Fortress/Merlin level, even a merge of everything into Merlin's Phortress. But it does isolate framework from having to adapt rapidly, meaning that those contracts will be very stable. Because we do need code that can change quickly and adapt quickly, even though we may not be sure whether the change is "the right thing". And concensus across all of Avalon may not be the right method for it. However, changes to a reference container, which is equal to changes to framework, does require concensus (stability is paramount). /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
