production ready and can it handle heavy loads or is it for light
testing only ? ---also will AOLserver for windows be supported in the
I've never tried AOLServer under Windows, so I can't tell you how well (or how poorly) it works. But the Windows code has been removed from the AOLServer 4.x snapshot that's available at www.aolserver.com, which means that you shouldn't bet on having a Windows version of AOLServer in the future.
Now, there were a few unofficial aolserver-win32 compiles (check the new-file-storage), but they are just that UNofficial (though i do use it for development purposes).
If you do do search on this bboard, you will see that there are problems with win32 aolserver -- file up/downloads aren't working well, it's a pain to make it use graphviz, etc.
Bottom line -- you should NOT use it for production system.
AOLserver 2.x on Windows is still being used on some production sites. (Yikes.) One person doing this has talked to me about upgrading to 4 and will probably do so once there is a stable release.
AOLserver 3.x for Windows is not being maintained by anyone and
is certainly not production quality for the reasons mentioned above
and in previous posts. A few people are using it on laptops or for testing. I don't know of any sites using it, but let me know if you find some!
I'm working on AOLserver 4 for Windows in my spare time. It is pretty
stable and has many bug fixes, including those for uploading files. OpenACS runs adequately but not perfectly on it.
I don't know of anyone who has tested OpenACS with AOLserver 4
on non-Windows platforms so I'm not entirely convinced that the current problems are Windows related. (Some problems are known to be in OpenACS. Hopefully these will get ironed out in time for OpenACS 4.7.)
Incidentally, TCL 8.4 was released on September 10th
So hopefully AOLserver 4 final will be along shortly as well.
Could you tell us more on how well you've found that strategy to work, and how you think it would be most effective to support AOLserver on Windows going forward?
E.g., how hard is continually forward porting the Windows code whille tracking the AOLserver core going to be? Can you comment on any possible alternate strategies, e.g., Cygwin, using a Posix thread library on native Windows, etc.?
Finally, for my own curiousity, what's the driving force behind your own interest in seeing AOLserver run well on Windows?
My changes so far have mostly been to improve the project files in the build process and to pull forward the code that got ripped out. Most of the porting issues are pretty standard - using SOCKET instead of int, line ending stuff, etc. The version that I am distributing an installer for at this instant is based on AOLserver b1-era code. It is roughly equivalent to the AOLserver 4-UH distribution from acs-misc (which came first), except for the installer and several bug fixes. I'm currently internally testing a version of AOLserver from the tip of the tree. I linked it against the RedHat pthreads library, which brings the Windows code much more in line with the non-Windows code. I've haven't tested this version very heavily and I don't have an installer for it yet, but it *seems* to work as well or slightly better than the one I have up right now.
I use CVS, WinMerge, and some perl scripts to keep my development tree up-to-date with the AOLserver changes. It isn't very hard to bring changes AOL makes over to my version. The only problem would be if they started to make extensive use of APIs that aren't available on Windows, and that shouldn't happen before a stable v4 is out anyway.
When I last looked, Cygwin was missing many of the pthreads functions that AOLserver was using. I think this might no longer be true. If all the API functions used are in Cygwin, it is usually just a matter of tweaking some Makefiles to get something to run under it. There would be a performance hit because of the emulation libraries of course, but it would ease the transition for people used to developing on Unix.
I've been driven by a few things. One is that I'm much more comfortable programming on Windows since I worked as a Windows developer for a few years. (For MIT's WinAthena project.) Another reason is that I needed close integration with Windows programs - for example, using OLE automation to automatically log MSN messenger chats on the website or authenticating our Windows users against the ActiveDirectory. It is easier to run these on a single box. And using Windows in a mostly-Windows shop means that it will be much easier for someone to carry on my work after my contract expires next year. Finally, until I got a second box up and running, I had to host my site on my main development machine, which has to be Windows for non-OpenACS related reasons.