Forum OpenACS Q&A: AOLserver and OpenACS

Posted by carl garland on
Today we had an interesting discussion in the weekly AOLserver chat that occurs every Thursday at 4 PM EST and I would encourage any/all to join those chats. The issue turned to the need for a better AOLserver community website to better coordinate/communicate what is going on among all the disparite coders. I mentioned that I had seen the proposal for an AOLserver subsite on a proposed new OpenACS site design in a thread here. This excites me very much because I think this is something that is poorly missing and lots of *synergy* cross pollination that could occur between OpenACS and AOLserver communities isn't currently happening.

While technically AOLserver is not OpenACS and vica / versa there definitly is a lot of common objectives that work in both camps favor. The OpenACS community is much larger than the AOLserver community but plans for AOLserver enhancements/addons should be of interest to the OpenACS crowd. Some of these include:
  • A set of standards for coding/doc for AOLserver modules
  • A testing framework for modules
  • A ns_encrytion module
  • A UDI/WDSL/SOAP module
  • Few other items
Much of this is already underway but sourceforge is not cutting the mustard for a place where the AOLserver community can effectively communicate/coordinate. Anyway while I hope I am not presuming on the OpenACS community but I think this is one project that would benefit all if there would exist an AOLserver subsite on the new OpenACS site. ScottG is developing his own internal solution for a community site currently but is months away according to him from being ready to use.

Anyway comment anyone?
Posted by Neophytos Demetriou on
Carl, I suggest we postpone this until the dotLRN issues are resolved. There's a thread under way. I'm willing to support an AOLserver subsite at but I will only post my arguments as soon as the dotLRN discussion/issues are resolved.
Posted by defunct defunct on
I'd very much lie to see that Carl.. sure its a good idea
Posted by Jun Yamog on
I think it would great to have both communities work with each other.  Why not have both in site. can point to their subsite.

Its also good to have a good relationship with OpenACS and aolserver as new developers and non developers will see that both platform is alive and kicking.  I think both will benefit from one another.

Posted by Lars Pind on
I agree. Given that AOLserver and OpenACS are so closely tied, it wold be great to have the community here.

In fact, it would be great if more C hackers would pick up AOLserver and start hacking a bit more on it.

If we could get to the point where we could make a technical choice of whether such and such piece of code was best written in C as part of AOLserver, or in Tcl as part of OpenACS, that would suit me fine. The request-processor is one obvious example.

Add to Carl's list above webDAV support.


PS! Crazy thought of the day: Would there be any way that we could get Apache modules to work with AOLserver?

Posted by carl garland on
I think I should point out that when I was refering to the AOLserver community what I mean currently is the AOLserver module making community. There is a clear separation between the folks who make the core server at AOL and those members of the community that develop modules although the community does submit patches to the core that are *sometimes* incorporated back into the main tree. This is unfortunate but simply the case so
Why not have both in site. can point to their subsite.

this is not what I was trying to ask for. is under the control of Digital City and what happens there is out of our control. However there is much model work that is redundant because there is no clear coordination/communication between the module developers. A single tent (possibly subsite hosted here) would really help push the AOLserver module platform to more efficient development. Down the line Scott G has very ambition plans to make the core capable of being much more than the HTTP application server of today but that discussion is for another time.