Forum OpenACS Q&A: Response to nsjava staus

Collapse
44: Response to nsjava staus (response to 1)
Posted by Don Baccus on
I'm curious about what others think about a couple of possible issues.

Java isn't "true" Open Source (though programs written in Java frequently are).  We've done a lot of work to make sure that we provide a 100% Open Source OpenACS 4 solution.  Of course, we also provide an alternative based on proprietary Oracle.  My main concern isn't to quibble over whether or not "free as in beer" is better or worse than "free as in speech".  My concern's more practical - can third parties like us bundle up a JVM in a "download an instakit" package, or are potential users going to have to download a compatible JVM themselves?

Because that kind of packaging - download a big chunk 'o stuff from openacs.org, wave a magic wand, and poof! you have a (dotLRN/dotWRK/dotWHATHAVEYOU) up and running - is something we've talked about pushing for vertical apps the community develops.

I don't know the answer to this, which (of course) is why I'm asking.

Then there's also the issue of competion for computing resources on the webserver machine itself.  Heavy use of Java pieces means yet another consumer of resource potentially on the scale of AOLserver and  the RDBMS.  I've also seen some interesting information about the scalability of one JVM due to lock contention issues (shown me under an NDA) so there's another tuning issue to worry about if you're going to run a large-scale service.

Before anyone says "yet another reason to support Apache" let me point out that the same issue exists if you couple a JVM to Apache.

This not only leads to potentially more complicated sysadmin requirements but leaves us open to statements like "if we just use a 100% Java solution life will be much easier".

Having said all this ... the fact is that the idea of being able to rapidly integrate with WebDAV and the like is *extremely* attractive.  I'm not knocking the attractiveness but ... let's think about the possible headaches involved with being too quick to decide that integration with Java services is the right long-term solution.

I don't think there's any doubt that in the short-term this is going to be the right solution for some of our integration problems, though.

If I had to vote today I'd probably vote for a quick push to get TclSOAP integrated (DaveB and Roberto seem very close and I gave them some hints on how to work around the "package requires" issue that might be useful), because it avoids all of the potential hassles that being dependent on having a compatible JVM around might lead to.

On the other hand, Dan's right that having a WebDAV client doesn't bring one close to having a WebDAV server and nsjava seems like the obvious short-term solution to that.  I'm glad he's looking at mod_dav (is the Zope WebDAV support Open Source and not Java-based?  Is this possibly another place to poach code?) because the long-term appeal of this should be obvious, too.

There's no doubt that a lot of Java stuff is out there and there will be more and more as each day goes past.  Being able to rapidly integrate is a big plus despite the potential hassles.