on 2/1/01 5:54 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> Yes, Turbine came first. And it implements what it includes quite well. No
> question. But part of being first is deciding what to do when the rest of the
> world tries to catch up, and standardizes APIs for some of the features you
> implement. This is a strategic decision that the Turbine community needs to
> make for itself.
I think that the decision is clear. :-)
> The effort cost to me of involving myself in that community, to help you think
> about if you want to conform to J2EE API patterns (and contributing code if
> you did -- otherwise it wouldn't scratch any of my itches) would far exceed
> the effort cost of implementing a connection pool that does something similar
> to what Turbine provides, but does so in a manner compatible with the standard
> that came along later.
I don't agree that it would far exceed the effort cost.
> In my idealism of last year, I assumed that I would have enough available
> awake hours to do so. I simply don't have the cycles to engage in yet another
> high volume / high quality email list, or the emotional energy to put up with
> the anti-JSP sentiment that would undoubtedly come my way.
But you have enough time to re-write source code that was already written?
You have enough time to maintain yet another re-write of something that
already exists?
Your argument is silly to me because you are arguing that it code re-use is
a bad thing and we all know that isn't true.
> What I will do for Turbine, however, is work to give you the best possible
> servlet container on which to run it.
That's good to hear.
> Software should evolve. It should get better. But, if you want software to
> be used on large scale projects with lifetimes measured in years (not months),
> you need to be serious about backwards compatibility on APIs.
That is exactly why I like a license like the BSD/ASF license. It allows you
to take a snapshot at any point in time and develop on it and never have to
worry about giving anything back.
That said, in the case of webapps, Servlets and Java, they are not mature
enough technologies to be able to able to count on a stable product with
API's that never change for years...anyone believing that is kidding
themselves.
> I'm not familiar with the details of Sam's specific issues -- what I was
> echoing is agreement with the gist of the points he was making.
His overall points were good, but the examples were incorrect. :-)
> In fact, my
> personal experience is that it goes beyond APIs -- how many times have you had
> to go back and change your build scripts to keep up with the rate of change in
> Ant?
You know what? I'm really ok with updating my build scripts. It isn't that
big of a deal to replace <copyfile> with <copy>.
What happened to believing that software evolves? :-)
> Changing the fundamental APIs was not my idea. But, the suggested approach
> was better -- and if you're going to do it, before an x.0 release is exactly
> the time to make those changes. Or, would you rather see the fundamental
> interfaces change on every dot release (Tomcat 3.0 -> 3.1 -> 3.2 -> 3.3 comes
> to mind)?
I was giving an example...
> For a counter-example, you might look at how Struts bends over backwards to
> support the APIs of the 0.5 milestone release, even in the face of pretty
> substantial improvements. The number of developers, and the amount of already
> existing code, impacted by these changes was *substantially* higher than the
> number of people who have written Valves to date -- so it was worth the
> investment in effort.
Yep.
> Had the Valves change actually been made in 4.1 instead of 4.0, you would
> certainly see deprecations and backwards compatibility support.
Even still deprecations don't entirely solve the problem.
> NOTE: The servlet and JSP APIs are *still* not finalized -- the specs
> implemented by the current code are "Proposed Final Draft". Any changes that
> happen in the final drafts must, of course, be reflected in Tomcat for it to
> remain true to its mission of faithfully implementing those specs.
NOTE: The Turbine and Avalon and Ant and Struts and and and and API's are
*still* not finalized -- the specs implemented by the current code are
"Standing on the heads of the developers". Any changes that happen in the
final drafts must, of course, be reflected in any applications for it to
remain true to its mission of faithfully implementing those specs.
:-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
