Skip ahead to the "<substantive-discussion>" section if
you're bored with the other topics in this thread.
[EMAIL PROTECTED] wrote:
>
> But what you are doing is a fork by all definitions that
> I know.
>
It's an alternative implementation of some of the Catalina
interfaces, but it's clearly not a fork. I'm using this as a
working definition: A fork refers to what you do in a revision
control system when you want to work independently on two
versions of the same code. By extension, on Open Source projects
it means taking a copy of the code base and making your own
copy that isn't kept synchronized with the mainline branch.
MinTC steals a little bit of code from some of the
o.a.c.core classes, but it doesn't copy any of them. What
it uses of the Catalina code, it uses completely intact
(I'm currently tracking CVS HEAD).
So it's not a fork. Forks suck. Alternative API implementations,
on the other hand, are generally considered a good thing.
Some spec processes even require them!
> You must at least try first.
>
I did. Don't take my word for it, it's in the archives.
<substantive-discussion>
I rejected the idea not because it was met with hostility
(I got good feedback), but because the discussion (on
tomcat-dev) convinced me that it was not the right
technical solution.
It comes down to the fact that totally
generic code has some rather extreme practical drawbacks.
The classes within o.a.c.core,for example, need to be
able to depend to some degree on each other's innards.
As Craig said:
"Within a particular package (org.apache.catalina.core),
I don't see a problem with the classes depending on
each other's insides -- the package as a whole is
designed, as a unit, to provide the required functionality
for that package."
o.a.c.core's required functionality is simply very
different than that of MinTC. MinTC has such a different
audience that it didn't seem reasonable to
saddle Tomcat 4 with MinTC's requirements. Integrating
the two would require that every last bit of functionality
was somehow modularized out of Tomcat 4 core, and that's
undesirable.
It's like making a combination jackhammer and framing
hammer just because they both have the word "hammer" in
their name. Sure, you could do it, but it would be silly.
Right tool for the right job, and all that.
The whole "write very specific tools but make them
interoperate" thing ("The Unix Philosophy") isn't for
everyone. Some people prefer other approaches, like
extreme factoring and adding loads of hooks. It's all
good. Knowing MinTC is a Unix-philosophy sort of project
might make it easier to understand where I'm going
with it.
</substantive-discussion>
Again, the feedback is good. It all helps, especially
the architecture discussion, even if it's negative.
(Although I can't help but wish some of the people
commenting now would have piped up earlier :-)
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
