Well, not really. But now that I have your attention, I want to point out that there is apparently a relatively easy way to get a huge amount of integration mojo and buzz (both steak and sizzle) that may be lower hanging fruit than any of the Apache strategies that have been bandied about.
While reading up on the SOAP progress, I ran across Nick's idea for a tool that converts service contracts into SOAP web services. Now, not being a programmer, I had no idea what kind of stuff that would expose. So Nick was kind enough to send me a list of the service contracts running on his apparently not-particularly-loaded-up dotLRN instance.
What I saw got me very excited. IMS Enterprise. WebDAV. Workflow. I can only imagine what else is available from a fully loaded installation. If I'm understanding the situation correctly, then a good chunk of the rich, sprawling set of functionality that is OACS can be exposed as web services with just a few weeks of work to build Nick's sc2ws thingie. Again, if I'm really getting what this means, then it would blow away any mod_proxy or mod_whatever integration with Apache. Instead of just providing buzz value, it would actually provide ways for developers of other systems to add real and substantial functionality to their apps through SOAP integration with OACS, whether those apps run on AOLServer or Apache, or are written in TCL, Java, PHP, or Eiffel. As a bonus, it clarifies the proper roles of AOLServer and OACS in the application stack by removing the HTTP server from the conversation.
I dunno. Am I missing something?