Forum OpenACS Q&A: AOLserver 3.5

Posted by David De Graff on
I noticed that AOLserver 3.5 was released in late September. It's said
to include 'several major improvements the Tcl library, memory
management, and overall performance'.

I'm curious as to why OpenACS installations use patched versions of
AOLserver rather than the stock code. From reading various threads I
gather that this relates to internationalization code (I18n) and maybe
some memory leak fixes for older versions of AOLserver.

Are these guesses correct?

Is there any chance of the OpenACS-related patches being merged into
the main AOLserver code? I see that a set of such patches has been on
the AOLserver site since June and is still assigned to nobody.

If the AOLserver team won't accept OpenACS-related patches, what would
be required to modify the patches so that AOLserver 3.5 can be used
with OpenACS? Does anyone know if this would be worthwhile? (I would
guess not, since it's a new release and people have been busy with
getting 4.6 ready.)


2: Response to AOLserver 3.5 (response to 1)
Posted by Jamie Rasmussen on
The main remaining issue is the internationalization code.  OpenACS also requires several additional modules that were not in the AOLserver source tree.  These included nsoracle, nssha1, a working version of nspostgres, etc.  For a long time, AOL was unresponsive to suggestions and patches, leading to a number of forked versions (OpenACS's isn't the only one) and causing much confusion for new users.

In the past few weeks, there's been a rather abrupt turnaround.  Many of the modules scattered across the web have been incorporated into the AOLserver SF tree, often with patches that aren't in the OpenACS version.  (The AOLserver nspostgres is still broken.  Certain people here have been given the ability to import the fixed version but have been swamped with 4.6 and other work.)  Nathan, Kriston, and Jim from AOL have been coming to the weekly AOLserver chats on AIM to get feedback from the community.  So I'm optimistic about OpenACS being able to run on a stock AOLserver distribution sometime soon.  I suggest joining the AOLserver mailing list and weekly chats if you haven't already.

3: Response to AOLserver 3.5 (response to 1)
Posted by Bernd Eidenschink on
Hi David,

AOLserver 3.5 seems to be some kind of interim release to the upcoming 4.0 Version. The latter incorporates i18n support as you can see in CVS on sourceforge ("encoding.c", new in 4.0). Seems like you can set different encodings based on the mime type of the returning page/item, but not on a page per page manner using commands -- but I don't know for sure, just a first guess.

I compiled nssha1, nscache and nsopenssl with success against 3.5. As usual you have to increase the stack size parameter in the config file of nsd (default is 128x1024) if you use the server for big projects like OpenACS and others.


4: Response to AOLserver 3.5 (response to 1)
Posted by Jeff Davis on
I ran through a test with aolserver 3.5 and everything worked (with the exception of some stuff in acs-lang which needs the i18n patches).  Jon Griffin reported not seeing streaming output from one of the install
scripts (I did not see it but I am running a plain redhat 7.3 install
and it might have something to do with tcp windows or other esoterica).
5: Response to AOLserver 3.5 (response to 1)
Posted by Andrew Piskorski on
I have not tried it myself, but last I heard on the AOLserver list, there are still some binary file upload and/or other somewhat obscure problems with 3.5, which as far as I knew had not been fixed yet.

However, while it's not reflected in the ChangeLog in cvs (yet?), nor as far as I recall announced to the list, from the cvs log it looks like there have been a lot of commits to the 3.5 branch in the last couple weeks, including things like fixes to that binary file upload bug. So my guess is most problems people have had with 3.5 will probably go away if you get the latest version out of cvs.

And yes, according to the AOL folks, 3.5 is supposed to be feature equivalent to 3.4.2, but with the old 3.x build process for the Tcl stuff ripped out and replaced with the "use the stock Tcl distribution" build process from 4.0. Plus a few other 4.0-style changes like putting all the docs into man page format.

That's what I understood anyway. But again from the 3.5 cvs log comments, it looks like they're back-porting some other 4.0 features into 3.5 as well. For example:

2002-10-14 19:21  jgdavidson 
   * nsd/tclsock.c: Updated to work without a server.

That sounds related to the AOLserver 4.0 ability to load into a tclsh and be used without running AOLserver per-se at all. So I suspect they're putting in the work to have the 3.5 codebase track the 4.0 codebase at least somewhat more closely. If you really wanted to know for sure, of course the thing to do would be to ask the AOL folks (Jim, Kriston, etc.) directly.

6: Response to AOLserver 3.5 (response to 1)
Posted by Carl Robert Blesius on
Jamie, what would you recommend on making the OpenACS i18n code a none issue? Any information would be great.
7: Response to AOLserver 3.5 (response to 1)
Posted by Jamie Rasmussen on
I've never implemented i18n myself so I'm not familiar with all of the relevant issues. Here is what I understand/hypothesize, and hopefully those that know better will correct me where I'm wrong:
  1. AOLserver (3.3 era) didn't support encoding stuff. Arsdigita patched AOLserver to support it, adding their functions to the C and TCL APIs. (ns_charsets, ns_encodingfortype, ns_encodingforcharset, etc.) acs-lang uses these functions.

  2. AOL didn't incorporate the patches. We don't know if there is something about these patches in particular that they don't like, but we don't think there is. Based on their actions the past few weeks, I think they will be more welcoming now.

  3. But as Bernd mentioned, in AOLserver 4.0 (at least) they've already implemented some similar functions. 4.0 uses these functions internally and exports them in the C API. (Ns_ConnGetEncoding, Ns_ConnSetEncoding, Ns_GetEncoding, Ns_GetFileEncoding, Ns_GetTypeEncoding, Ns_GetCharsetEncoding) However, it doesn't export them in the TCL API.

  4. Making acs-lang work with AOLserver 4.0 probably just requires making these functions accessible in TCL and maybe adding the few other C and TCL functions Arsdigita added for setting encoding on a page-by-page basis. Given the patch files floating around, I'm guessing this would not be difficult for someone who knows AOLserver and acs-lang well enough.

  5. But before beginning on that work, the people interested in doing it should join the AOLserver chat and ask the AOL crew about their opinion on the matter. I might be underestimating the difficulty or they might have some secret objection to incorporating the work. They might even be planning on doing it themselves and just haven't told anyone about it. 😊