> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > On Fri, 5 Apr 2002 18:11, Leo Sutic wrote: > > > From: Leo Simons [mailto:[EMAIL PROTECTED]] > > > > > That is a problem of arranging code into packages and > subpackages, not > > one of naming the packages. See below for how I want it done. > > > > ExcaliburComponentManager was actually a good name, since it was > > *the* ComponentManager implementation for all of Excalibur. > > *bzzt* wrong > > I have never used ECM but regularly use excalibur packages. > It happens to be > *a* CM that is contained in excalibur but it is just one of three. > > > As opposed to: > > > > SingleThreadedComponentManager > > NetworkComponentManager > > SOAPComponentManager > > > > What is easier? > > Bad examples. Implementations are rarely done this way. They usually > implement the same features in different ways. Consider Phoenix, ECM, > Fortress and Merlin - all of them basically do the same thing > (act as a > container for components).
On this point I agree with Peter. Besides, the distribution mechanism must be pluggable (i.e. a component that the container can use to distribute the selected components). And I don't know of one situation where a "singlethreaded" component manager would really be useful. As soon as you add a new thread (inevitable), you chance breaking the system. > Fortress is a new and improved ECM. Under your system we > would be forced to > use arbitrary name decoration like the dreaded "Classic", "Modern", > "Post-Modern" or appending version numbers. Very confusing for users. Fortress is IMO good enough of a name. > > We do not want several competing event packages. > > yes we do. If we did not allow that then the ECM, fortress and Merlin > products would not exist because Phoenix predates them all :) Well, we don't want so many that they confuse users. However, a little healthy competition is a good thing. > > I want: > > You want the impossible and the impractical. Nothing is 100% > correct for 100% > of the situations so you can never have a perfect interface > and competing (or > in our case more likely cross fertilizing) products are necessary. Be careful not to throw the baby out with the bath water. We currently have 30 Excalibur sub projects. Some of which are associated: bzip2, zip. Those could theorhetically be put in the same subproject (archive) with two jars produced out of it. Unfortunately, if we had 30 mideaval names for Excalibur, we would have a real mess on our hands. Leo's point, which is valid, is that having all mideaval names is more counter-intuitive than having a name more directly linked to what the package represents. I.e. the event based package is in a good name for it right now. Abstract names are good if they are few, because our minds can handle that. However, I personally start losing track after about a dozen. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
