8 ms·

Anyone use AOLServer recently?

73 points by pelle 16y ago

dlsspy 16y ago
It came up in a conversation around the office last week, but I haven't heard of a deployment in years.
patrickgzill 16y ago
I have a number of clients using it, they are all happy with it in terms of performance and reliability. 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. For example, one client is still running code originally written in 2002-2003, they just updated the templates. 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. 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.
100k 16y ago
That brings back memories. I did the ArsDigita "bootcamp" back in 2001. Fun times.
- malloreon 16y ago
  Sup AD bootcamp buddy. I think I did it sometime in 2000. Really fun weekend.
jeffclark 16y ago
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. It's nuts. TCL's syntax is extremely simple, but overall appears to be really powerful. 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. The included ticket tracker makes for an unbelievable customer service platform, too.
- cmeiklejohn 16y ago
  Zipcar? I know they are actively hiring for OpenACS devs...
  - gecko 16y ago
    Zipcar had been trying to move off Tcl, but I don't know how seriously they were focused on that or what their status is. My impression is that had much more to do with trouble finding experienced devs than any issues with the technology stack, though.
    - davidw 16y ago
      I'm a big Tcl fan, and had a hand in the most recent version of Ousterhout's book, but it's a bit of a surprise that they picked Tcl, as it's honestly not that popular these days. Wonder who it was that made that decision. If nothing else, sounds like round 26339132 of the Tcl marketing "fail": company complains about not finding people, while simultaneously hiding themselves from the community of the product they're using, and hiding the fact that they're using the technology in question.
      - jeffclark 16y ago
        Where are the OpenACS communities at? One of the most frustrating things of the new job is only finding articles/posts/whatever from 10 years ago.
        patrickgzill 16y ago
        OpenACS.org and the IRC channel is all I know about...
      - cmeiklejohn 16y ago
        I assume they picked TCL because they are tied to OpenACS. I'd assume it's no coincidence that one of the ArsDigita's problem sets for OpenACS involved a reservation system with OpenACS and PL/PGSQL.
deleted 16y ago
[deleted]
udp 16y ago
I'd no idea this existed - quite interesting to flick through the source. I wonder how it benchmarks compared to Apache or Lighttpd?
SwellJoe 16y ago
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. 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.
dkarl 16y ago
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 ;-) 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. 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. 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.
- jrockway 16y ago
  Sounds odd, but of course, strings are all computers store anyway; your address space is a big string (with holes, perhaps) from 0x00000000 to 0xffffffff, and that's where everything is. (And yes, if you have a 48-bit or 64-bit address space, the string is longer.) So what's strange is not the representation but how it's not hidden from the programmer.
  - chwahoo 16y ago
    One big string? My computer just stores one huge number :)
- msofer 16y ago
cd34 16y ago
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. 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. I think Philip Greenspun's thinking on CMS design and entrepreneurship had quite an impact on my thought processes. OpenACS's code - not really a stellar example of well written code. Functional, but messy.
toddml 16y ago
We use it to the tune of a few hundred million requests/day
- iphoneedbot 16y ago
  Is that what you guys use on Bit.ly
  - deleted 16y ago
    [deleted]
mhd 16y ago
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…
- sigzero 16y ago
  teacup does everything I would expect a reasonably good package manager to do.
cmeiklejohn 16y ago
acts_as_openacs: https://github.com/jadeforrest/OpenACS-on-Rails https://github.com/jadeforrest/OpenACS-on-Rails
silas 16y ago
$ curl -s http://bit.ly/test http://bit.ly/test | grep AOLserver AOLserver/4.5.1 on http://127.0.0.1:7200</P&#62 http://127.0.0.1:7200
- getsat 16y ago
 I wonder why they have that there when they're actually running nginx: 689 ~ % curl -i bit.ly/test HTTP/1.1 301 Moved Server: nginx/0.7.67 Are they using AOLServer behind nginx? That seems bizarre.
 - patrickgzill 16y ago
 Nothing bizarre about it, given that nginx can serve many thousands of slow-receiving web clients while AOLserver usually uses 1 thread per connection - so 20 slow clients can effectively stall 20 threads. Thus the strategy is to use nginx to serve static content like .css .js .png .jpg .gif, plus grab the dynamic content from AOLserver and buffer it out to the order of magnitude slower clients (10Mbps client vs 100Mbps or 1Gbps link between nginx and AOLserver).
 - getsat 16y ago
 Thanks for the explanation. I've never used AOLServer and was unaware of its limitations. Seems to have the same limitations/scaling problems as the two most popular Apache MPMs. :) My main setup nowadays is HAPRoxy -> nginx load balancers -> Unicorns.
msisk6 16y ago
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.
minimax 16y ago
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. 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.
- davidw 16y ago
  > Each function definition is preceded by documentation of its purpose and side effects. That's the Tcl style: https://github.com/das/tcltk/blob/master/tcl/generic/tclStringObj.c https://github.com/das/tcltk/blob/master/tcl/generic/tclStri... Tcl's C code is very nice.
- jzcoder 16y ago
  The Ns module API was also very clean. This is why we choose it to embed our libraries and expose an HTTP interface to our other internal applications. It's worked reliably for this purpose for years. Since all our development work is inside our module wrapper, we have no immediate plans to move away from AOLserver. It just works fine as a lean web server.
Vivtek 16y ago
I've used it continually since 1996, and I'm still using it now.
omarqureshi 16y ago
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.
k2pts 16y ago
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.
patrickgzill 16y ago
Companies still doing AOLserver/OpenACS/dotLRN stuff: http://solutiongrove.com http://solutiongrove.com http://acspropel.com http://acspropel.com OpenACS.org and dotLRN.org are the sites for the OpenACS and .LRN (education oriented) toolkits that run on top of AOLserver.

73 points by pelle 16y ago

It came up in a conversation around the office last week, but I haven't heard of a deployment in years.

I have a number of clients using it, they are all happy with it in terms of performance and reliability. 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. For example, one client is still running code originally written in 2002-2003, they just updated the templates. 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. 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.

100k 16y ago

That brings back memories. I did the ArsDigita "bootcamp" back in 2001. Fun times.

malloreon 16y ago
Sup AD bootcamp buddy. I think I did it sometime in 2000. Really fun weekend.

jeffclark 16y ago

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. It's nuts. TCL's syntax is extremely simple, but overall appears to be really powerful. 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. The included ticket tracker makes for an unbelievable customer service platform, too.

cmeiklejohn 16y ago
Zipcar? I know they are actively hiring for OpenACS devs...
- gecko 16y ago
  Zipcar had been trying to move off Tcl, but I don't know how seriously they were focused on that or what their status is. My impression is that had much more to do with trouble finding experienced devs than any issues with the technology stack, though.
  - davidw 16y ago
    I'm a big Tcl fan, and had a hand in the most recent version of Ousterhout's book, but it's a bit of a surprise that they picked Tcl, as it's honestly not that popular these days. Wonder who it was that made that decision. If nothing else, sounds like round 26339132 of the Tcl marketing "fail": company complains about not finding people, while simultaneously hiding themselves from the community of the product they're using, and hiding the fact that they're using the technology in question.
    - jeffclark 16y ago
      Where are the OpenACS communities at? One of the most frustrating things of the new job is only finding articles/posts/whatever from 10 years ago.
      - patrickgzill 16y ago
        OpenACS.org and the IRC channel is all I know about...
    - cmeiklejohn 16y ago
      I assume they picked TCL because they are tied to OpenACS. I'd assume it's no coincidence that one of the ArsDigita's problem sets for OpenACS involved a reservation system with OpenACS and PL/PGSQL.

deleted 16y ago

[deleted]

udp 16y ago

I'd no idea this existed - quite interesting to flick through the source. I wonder how it benchmarks compared to Apache or Lighttpd?

SwellJoe 16y ago

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. 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.

dkarl 16y ago

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 ;-) 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. 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. 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.

jrockway 16y ago
Sounds odd, but of course, strings are all computers store anyway; your address space is a big string (with holes, perhaps) from 0x00000000 to 0xffffffff, and that's where everything is. (And yes, if you have a 48-bit or 64-bit address space, the string is longer.) So what's strange is not the representation but how it's not hidden from the programmer.
- chwahoo 16y ago
  One big string? My computer just stores one huge number :)
msofer 16y ago

cd34 16y ago

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. 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. I think Philip Greenspun's thinking on CMS design and entrepreneurship had quite an impact on my thought processes. OpenACS's code - not really a stellar example of well written code. Functional, but messy.

toddml 16y ago

We use it to the tune of a few hundred million requests/day

iphoneedbot 16y ago
Is that what you guys use on Bit.ly
- deleted 16y ago
  [deleted]

mhd 16y ago

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…

sigzero 16y ago
teacup does everything I would expect a reasonably good package manager to do.

cmeiklejohn 16y ago

acts_as_openacs: https://github.com/jadeforrest/OpenACS-on-Rails https://github.com/jadeforrest/OpenACS-on-Rails

silas 16y ago

$ curl -s http://bit.ly/test http://bit.ly/test | grep AOLserver AOLserver/4.5.1 on http://127.0.0.1:7200</P&#62 http://127.0.0.1:7200

getsat 16y ago
I wonder why they have that there when they're actually running nginx: 689 ~ % curl -i bit.ly/test HTTP/1.1 301 Moved Server: nginx/0.7.67 Are they using AOLServer behind nginx? That seems bizarre.
- patrickgzill 16y ago
  Nothing bizarre about it, given that nginx can serve many thousands of slow-receiving web clients while AOLserver usually uses 1 thread per connection - so 20 slow clients can effectively stall 20 threads. Thus the strategy is to use nginx to serve static content like .css .js .png .jpg .gif, plus grab the dynamic content from AOLserver and buffer it out to the order of magnitude slower clients (10Mbps client vs 100Mbps or 1Gbps link between nginx and AOLserver).
  - getsat 16y ago
    Thanks for the explanation. I've never used AOLServer and was unaware of its limitations. Seems to have the same limitations/scaling problems as the two most popular Apache MPMs. :) My main setup nowadays is HAPRoxy -> nginx load balancers -> Unicorns.

msisk6 16y ago

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.

minimax 16y ago

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. 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.

davidw 16y ago
> Each function definition is preceded by documentation of its purpose and side effects. That's the Tcl style: https://github.com/das/tcltk/blob/master/tcl/generic/tclStringObj.c https://github.com/das/tcltk/blob/master/tcl/generic/tclStri... Tcl's C code is very nice.
jzcoder 16y ago
The Ns module API was also very clean. This is why we choose it to embed our libraries and expose an HTTP interface to our other internal applications. It's worked reliably for this purpose for years. Since all our development work is inside our module wrapper, we have no immediate plans to move away from AOLserver. It just works fine as a lean web server.

Vivtek 16y ago

I've used it continually since 1996, and I'm still using it now.

omarqureshi 16y ago

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.

k2pts 16y ago

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.

patrickgzill 16y ago

Companies still doing AOLserver/OpenACS/dotLRN stuff: http://solutiongrove.com http://solutiongrove.com http://acspropel.com http://acspropel.com OpenACS.org and dotLRN.org are the sites for the OpenACS and .LRN (education oriented) toolkits that run on top of AOLserver.