Forum OpenACS Development: OpenACS on Apache?

Posted by Rafael Calvo on

I think the last time this was discussed was around 2001 (

There are many reasons (technical and of marketing) for which being able to run openacs/dotlrn would be convenient, and things at openacs have changed a lot since 2001.

How big an effort would this be?
Would this be a worthwhile effort?



2: Re: OpenACS on Apache? (response to 1)
Posted by Talli Somekh on
There have been a lot of discussions, actually, since then. Some were with regards to a new modaolserver, but recently the best possibility (IMO) has been finishing up John Sequeira's work on Portable.NSD (


3: Re: OpenACS on Apache? (response to 2)
Posted by Jamie Rasmussen on
Also, starting with AOLserver 4.0 you can "load nsd" in a TCL interpreter to get access to many of AOLserver's commands.  (The commands that are missing require a connection, ns_adp_*, ns_return*, and a few others.)  I use this all the time to test the AOLserver API in tclsh, etc.

Just for fun, I added an ns_load command into my libnsd that allows you to also load AOLserver modules into TCL.  It is definitely a hack, but works for simple modules like nssha1.  You can see a screenshot at

I believe John was considering modifying portable.nsd to load libnsd if it was available and to fall back on the pure TCL implementation of the API if not - I don't know if he did.  Building on the work John and Michael have already done on portable.nsd I think it should be possible to run at least a basic OpenACS instance on TclHttpd or Apache without investing too many hours.

5: Re: OpenACS on Apache? (response to 3)
Posted by Malte Sussdorff on
Out of curiosity, wouldn't it make sense to load your libnsd into apache and modify the OpenACS core functions to either call ns_return_* (aso.) or the apache equivalent (if there is any, I fear there isn't for ns_adp_*), depending on what server it is running on ?
6: Re: OpenACS on Apache? (response to 5)
Posted by John Sequeira on

I think you're describing the approach mod_aolserver took.  I don't know too much about it,  but it's more complicated than just rewiring the return function.  The biggest issue with using a binary interface to wire openacs into another web server is that it has to be updated when the interface changes,  or rewritten for each new web server you want to support.  I think that's why the idea continues to not gain traction (aD tried it with both IIS and Apache).

I feel pretty good about the prospects of running portablensd under apache and iis,  and avoiding the binary issue by using fastcgi.  It worked well on the platforms I tried it on (apache 1.3x/win32 + apache 2/rh9)

I got hung up on implementing ad_form and the new listbuilder -- the templating code was too messy and too different from Michael's nstcl for me to reconcile.  I don't think it would be hard from someone better at TCL than myself (like Michael, say).

There were a few other issues,  but no show-stoppers.

fwiw,  I did plan to look for libnsd and fall back to tcl-only routines if they exist,  but I'm not sure if the functionality exposed in libnsd offers enough of a performance increase to justify the maintainence overhead (i.e. adding another row to the pnsd test matrix.)

4: Re: OpenACS on Apache? (response to 1)
Posted by Rafael Calvo on
Thanks for the update guys. I did a quick search on the forums and did not see anything recent, I should look more carefully.

What you are saying is very promising. I think that using Apache could be very usefull for the people developing webservices for openacs, besides also being better for those marketing openacs.



7: Re: OpenACS on Apache? (response to 1)
Posted by Jonathan Ellis on
I don't understand -- why did you need to implement ad_form in pnsd?
Good question.

nstcl implements a subset of the ns_ commands involved in processing adp templates,  and ad_form makes use of some of the ones that are not implemented.  Because of differences between how nstcl and aolserver implement these it's not a simple matter of implementing the missing ns_* procs.  Specifically, recursion is handled differently in the native and pure tcl libraries,  and ad_form relies on some globals (level, content) that don't necessarily have the same values at the same adp parse/emit stage.

The aD code's reliance on globals made it really hard for me to figure out what was going on, and ultimately I couldn't figure out how to bridge the two.  Michael C suggested just reimplementing ad_form,  as he did with the almost all the rest of the custom tags.  His reimplemented code relies much more on namespaces than on globals,  and is much cleaner to extend and debug.

Can this re-implementation of ad_form and some of the guts of the Templating System be just dropped into OpenACS without causing any problems? If yes, and if it really is, "much cleaner to extend and debug", then I'd personally like to see that code rolled back into OpenACS...