Forum OpenACS Q&A: Response to ns_java / ns_javablend

Collapse
Posted by Michael Feldstein on

Dan wrote:

As far as using jacl, I couldn't disagree more. Tclblend is designed to integrate with c-code, so it's a nice fit with aolserver as an independent module. To use jacl, you would have to reimplement aolserver in java, which would probably result in an aolserver clone that performed quite poorly, but had good integration support for java. It would be a huge task that wouldn't be worth the effort. Removing the memory leaks from tclblend would be a much easier task by comparison, and the use of ns_javablend would allow you to easily integrate java and tcl within aolserver.

I have nothing to say on the technical merits, of course, but I do worry about the future for AOLServer. I worry about the fact that 90% of the developer resources for AOLServer come from AOL, whose needs are often orthogonal to those of the OpenACS community.

I have floated these concerns privately to a few community members, and the answer I always get back is, "AOLServer is still better than pretty much anything else out there. Apache might be good someday, but it's not there yet." Etc. I understand this argument, because it's an awful lot like the one I gave my friends about why I was sticking with my Mac circa 1996.

I wouldn't be surprised if Apache and/or others (possibly including some Java-based competitors) close the gap on AOLServer on issues of performance and stability in the next year (or two). Once they have done so, their rather large developer base can start focusing more energy on features -- on making web servers do new and interesting things. When that happens, will the AOL bother to implement these new features? Will they need them? If not, will the OpenACS community be able to keep up? Is there any point in trying?

My suspicion is that, just as Apple found itself with nothing competitive about its OS other than it's (user) interface, AOLServer will someday (sooner than you think) find itself in a position where the only thing competitive about it is the (tcl/db) interface. If and when that day comes, we will have to do what Apple did, i.e., rip out the guts and start over, keeping mainly a lot of the interface stuff plus as much backward compatibility as they could swing without killing their effort to move forward. (Please, no flames about the OS X UI.)

If I'm right about this, then the community will probably have to make the things you like about AOLServer portable to another web server sooner or later. Inevitably, the first implementation will be a huge resource drain and have poor performance relative to the real thing. This is all the more reason to start now.

To see if I'm right, the question you have to ask is simple: Is AOLServer evolving as quickly as the competition? If it is, then no worries. If it's not, then no matter how far ahead it may be now, it is inevitable that it will be surpassed, at which point the huge investment of resources in OpenACS will start to lose value. How fast the competition catches up --and how fast it speeds ahead once it has caught up-- is simply a function of how far behind the competition is and how quickly they are catching up. Once you figure that out, then figure out how long it would take to polish an implementation of the API on another platform (mod_AOLServer, AOLServer J2EE, AOLServer.NET...whatever). If the latter timeline gets a lot longer than the former one, then the community has some serious problems.

All this is to say that perhaps Dan's specific objections to Jacl --as accurate as I'm sure they are-- may not be as compelling if one takes a longer view.