Forum OpenACS Q&A: Response to The whole java thing, Tclblend and Webmail

Collapse
Posted by Dan Wickstrom on
I would like to emphasize that this is just a proof of concept for using java in openACS devlopment and not a final solution for porting webmail. Most of the work on this project has involved adding java classes to replace the functionality lost by converting the sqlj statements. Yes it's true that mime coding/decoding would probably be better handled in TCL, but given the small number of people doing development/porting on openACS, it's easier for us to find ways to port the stuff from aD than to reinvent it.

I agree with Ben's comment about scalability, but for this phase of the development, I've been mainly concerned with the JDBC end of things and making the interface to the database functional in a generic way, so that future porting of java code will mainly involve rewriting the sql statements. In the short-term it would be easy to convert the message parsing side of webmail run as a standalone application that would run in a loop where it would sleep for some fixed amount of time, wake itself up and then process the mail queue, putting itself back to sleep at the end. The process could put logging information in the database each time it parsed the mail queue, and a watchdog process could be scheduled in aolserver to run periodically and check if the queue processing were working correctly, and if not, it could kill the current message parsing procees and restart it.

The message encoding is the main bottleneck in the current scheme, and it will require some investigation to work out a method for controlling a standalone java application in a robust and portable manner. Once I finish up the blob stuff and verify that I can send and recieve attachments, I will look into some of the possible alternatives.

The two main alternatives as I see it are to use JNI to embed a jvm in a loadable aolserver c-module, or to control a standalone jvm through a socket connection.

A JNI interface would probably provide a seamless interface to the java libraries, but the main problem with this approach would be that we would need to develop a loadable jvm c-module for aolserver. It seems like this would be doable, but I'm sure it's not a trivial exercise. Maybe somebody has already done this? I looked over at the aolserver site, and the only mention of java was the tomcat servlet engine, which from the sound of it, is not what we want.

The other alternative for interfacing to java would be to use a socket interface. Both aolserver and java have strong support for socket progamming, and I think it would be possible to provide a generic api in aolserver for issuing commands to a standalone jvm.

Anyway, I'm going to do some investigation on the two methods mentioned here, and if anybody out there has some other ideas, I would be willing to look into those also.