On Fri, 5 Apr 2002 18:11, Leo Sutic wrote:
> > From: Leo Simons [mailto:[EMAIL PROTECTED]]
> >
> > > Still trying to figure out whether this is an April Fool's joke
> > > that started two days ago, but I'd like to make a case for
> > > boredom, three-piece suits (gray ones) propose:
> > >
> > > excalibur.system -> excalibur.container
> >
> > The thread was started because we have a problem: excalibur can
> > contain multiple implementations of component managers, systems,
> > event packages, commands, etc.
>
> 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).
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.
And there is no single feature that separates any one out.
* ECM/Fortress integrate Pooling.
* Phoenix hosts multiple applications
* Merlin/Phoenix have stronger meta-data support (ie need to declare
dependencies and supported services)
etc.
I would love to see you come up with a name for each of them that is
representative and would be clear to users.
> Suppose a newbie to Excalibur is looking for a CM with the properties
> above and is faced with the JavaDoc for Excalibur. Where does he/she
> start looking for the CM implementation? You are basically forcing the
> newbie to read the package descriptions instead of just scanning the
> package names.
The same could be said of using names like Cocoon or Xerces for projects.
They don't represent what
> 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 :)
> We may need several
> implementations of the event api interfaces, but I do not want
It is not always possible to have a one-size fits all interface. It does not
make any engineering sense to restrict yourself in this way. If it is
possible to reuse an interface then all is good but if not then that should
not stop you implementing your own support.
> 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.
--
Cheers,
Pete
---------------------------------------------------
"Marriage, Friends, Religon -- these are the demons
you must slay in order to suceed in business.."
-- Mr. Burns, The Simpsons
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
