I happen to know of tens of thousands of running instances, and I'm sure many HNers will interact with one today. Can't say more ;-)<p>Aolserver is reliable and efficient. Tcl is reasonably efficient for most purposes (which is to say, dog slow but who cares?) though we drop down to C++ in many cases where Tcl might not be fast enough.<p>Tcl is a powerful but strange language. The heavy dependence on strings in its implementation is problematic, to say the least. An object of a particular type may be converted to a string representation, deleted in its original form, and then resurrected from the string representation later. That's not exotic functionality; it's normal in ordinary usage of the language, and it would invalidate the use of Tcl's reference counting for resource management. Therefore, when you define a new type that manages a resource (a resource such as a "future" object returned from C++ land, when you're waiting for an asynchronous operation to complete) you have to be sure NOT to implement working object->string and string->object conversion methods on that type. You have to implement those methods to signal an error to ensure that the object is never stored as a string and then resurrected later.<p>That's all fine and dandy, but that means you can't store objects of that type in a list, because a Tcl list is a string built from the string representations of its members. In case you were wondering how an object might be converted to a string, deleted, and then resurrected later from its string form, that's exactly what happens when you add an object to a list, dereference the original instance, and then retrieve that item from the list. Truly weird.
We used it, along with OpenACS for the Virtualmin website for about a year in 2005. It was better than the Joomla site that we replaced it with, in terms of reliability, performance under load, and maintainability. But, we finally got it right when switching to Drupal a couple of years ago.<p>I had no complaints about AOLServer. It was fast, reliable, small, well-documented, and did everything we needed it to do. I like Apache better, of course, because Apache can do vastly more...so many more developers just leads to more code being written. But, I never lost any sleep because of AOLServer, which as an IT guy, is my gold standard for good software.
I have a number of clients using it, they are all happy with it in terms of performance and reliability.<p>However they tend to be deployments based on work done previously (the dreaded "legacy" code) and for which it doesn't make sense to spend more money to rewrite the site in another language.<p>For example, one client is still running code originally written in 2002-2003, they just updated the templates.<p>Another is using the OpenACS.org codebase and is actively developing custom solutions for clients, where the client doesn't care what the technology is underneath the solution.<p>I personally think the ticket-tracker in OpenACS, were it cleaned up a bit more, would make an excellent lightweight ticket tracker hosted service for many small dev teams.
I just started a new job at [company you've most likely heard of if you live in a large U.S. city] and we use it here.<p>It's nuts. TCL's syntax is extremely simple, but overall appears to be really powerful.<p>Still trying to wrap my head around some of the more advanced things, but it apparently scales very well and has great community/group aspects built in.<p>The included ticket tracker makes for an unbelievable customer service platform, too.
Actually migrating the last openACS app over to Pyramid in the next week or so. Not from a failure point of OpenACS or AOLServer - both products have worked very well.<p>As far as performance, I found it to be somewhat akin to Apache + a moderate CMS. It scaled better than bare apache which at the time was a large consideration. Only one of the projects ever hit a point where scalability became a concern.<p>I think Philip Greenspun's thinking on CMS design and entrepreneurship had quite an impact on my thought processes.<p>OpenACS's code - not really a stellar example of well written code. Functional, but messy.
The Aolserver web server is one of the most readable C programs I've ever seen. Each function definition is preceded by documentation of its purpose and side effects. Unfortunately the modules tend not to be quite as clean. The development community is dwindling but exceedingly polite and helpful.<p>The one gripe I have is that the tuning parameters are not well documented (especially post 4.5.0). You have to study the source in order to dig out all the parameters you need to tweak in order to really make the server sing.
What's the current state of teacup? Working with the current web technologies, I'd miss the library support that Python/Perl/Ruby have, and building everything yourself and packaging that as a starkit is nice for desktop apps, but for servers…
I've used it continually since 2001, and I'm still using it now. The downside is that most companies have forked the OpenACS code internally (including universities using dotLRN) --- that code never made it to the outside world. If you needed an extension, it has always been the case that you had to write it yourself. Developers are indeed an often scarce good but that has worked well for those of us that are still around.
Scholastic UKs website is predominantly a Rails frontend app (with the exception of many PHP minisites and one OpenACS site) all talking to an OpenACS / PG / iSeries backend. It truly is a monument to over 10+ years worth of web development. Though the main reason towards the Rails switch was the lack of TCL developers, though, strangely enough, good local Rails developers are equally as rare.
Companies still doing AOLserver/OpenACS/dotLRN stuff:<p><a href="http://solutiongrove.com" rel="nofollow">http://solutiongrove.com</a><p><a href="http://acspropel.com" rel="nofollow">http://acspropel.com</a><p>OpenACS.org and dotLRN.org are the sites for the OpenACS and .LRN (education oriented) toolkits that run on top of AOLserver.
Well, I've used it a fair bit, always in conjunction with ACS or OpenACS. With the exception of supporting legacy TCL code, I can't think of a good reason to use it over Apache/Nginx with Ruby/Python nowadays.