On Fri, 5 Apr 2002 23:30, Leo Sutic wrote:
> > 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.
>
> Phoenix is a complete application and a project in itself. You can
> not compare a set of components like Excalibur to Phoenix.
Errr ... I haven't compared it to excalibur as a whole ... I compared it to
fortress, EC and merlin - all who do much the same thing.
> I would
> expect the CM in Tomcat to be called TomcatComponentManager. I would
> expect the servlet manager to be called TomcatServletManager or somesuch.
> I would not expect the javax.servlet.Servlet interface to be renamed
> javax.servlet.AlleyCat. Or animals.furry.AlleyCat or animals.furry.Servlet.
hmmm.
> Yes, but the implementations in Phoenix are not supposed to be used in
> other projects.
aren't they?
> > I would love to see you come up with a name for each of them that is
> > representative and would be clear to users.
>
> As I stated above, Merlin is only supposed to be
> used inside Phoenix.
Thats news to me. Merlin was specifically designed to work outside of phoenix
IIRC.
> > > 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.
>
> Or using Apache for a software foundation. But why do we give
> classes descriptive names?
We do.
> Why is EJB classes in javax.ejb and not in javax.coffeemachine? (Get it?
> *Enterprise* level java beans? Big stuff? Not just a regular coffeepot
> but a *machine*? Ain't I *clever*? No.)
ho hum.
> I do not know what experience you have with commercial grade development,
> or dealing with the people in charge of such, but the *only* way Avalon
> and Excalibur will be used in the real world by real companies
> is to write the code in such a way as to make it usable in a commercial
> environment. That means:
la ti di da.
> Period. Your battle for mindshare will be lost to some other project that
> manages to appear as being more professional. Compared to an apparent horde
> of mentally retarded juvenile coders, that will not be difficult. It will
> not matter one iota that...
I can see that you are a true professional and we need to emulate you much
more.
> Those are implementations. I have no problem with that and that is
> made quite explicit in the mail I wrote. Suppose we have three
> ComponentManager interfaces, competing. Or three logging interfaces.
> Oh, wait. We do. How good. So good, in fact, that we decided to hide
> all the implementations behind *one* common interface so we could just
> forget about all of that and code as if there were only one logging
> implementation. And what did we call the interface? Logger. How boringly
> descriptive and uncompetitive.
Simple problems have simple answers. However Even logging has at least 5-6
different interfaces. I still haven't heard you come up with a one interface
fits all probalems yet...
> > > 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.
>
> Agreed - but having several interfaces is something we "may need",
> not something we "want" just for the sake of duplicating effort.
> That is so obvious that I can only assume that we are misunderstanding
> each others mails.
>
> So my -1 stands.
And is worthless under apache rules ;)
--
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]>
