Forum OpenACS Q&A: Windows, AOLServer, and OACS

- AOL decided not to support Windows in future versions of
AOLServer. This doesn't mean that those versions won't run on
Windows; it just means nobody's going to make an effort to
ensure that it does.

- A relatively recent version of AOLServer (the current one?) still
supports Windows.

- Several people have gotten OACS to run on Windows, but not
well. Nobody has put a huge amount of effort into trying, though.

Questions:

- Is the above correct?

- Does OACS 4.x require now or --will it require in the next year or
so-- use of an AOLServer version under which Windows is no
longer supported?

- What important features in newer versions of AOLServer might
one have to give up in order to use the older,
Windows-supported version?

- What are the current known issues about running OACS on
Windows?

- If a company were to commit to getting the OACS running better
on Windows for the next 12-18 months, would they have to make
modifications to AOLServer in order to do so?

- If the answer to the above is "no," then how much work would
be involved with thoroughly debugging OACS on Windows?

- What parts of OACS and related components would the
hackers most likely need to be knowledgeable about in order to
debug OACS on Windows?

Thanks.

Bboard postings that might be useful, starting with the most recent:

• Has anyone got file upload working under win2k?
• AOLserver 3.3.1 for Win32 release available in new-file-storage
• Windows and OpenACS3/4

The AOLserver team *aggressively* removed Win32 support from AOLserver 4. I think they've removed the old Windows binaries from their webpages, they ignore Win32 bug reports, etc. Anyone for reviving OpenNSD? 😊 Getting OpenACS to run better on Windows definitely requires modifications to AOLserver, but nothing too difficult. OpenACS on Windows needs some minor debugging too, but again, nothing that requires too much effort for people who know the system.

OpenACS on Windows will never be "mainstream". I think it is mostly useful for development, ACS newbies who want to do the problem sets without learning Linux, etc. In my opinion, the most pressing need is for clear Windows-specific documentation, a reliable repository of patched AOLserver source and binaries, and (just getting greedy now) an installer to have the whole thing up and running in less than an hour.

You may want to consider getting mod_aolserver to work with Apache 2.0/Win32.  I would think that there would be less AOLServer to maintain if you were able to delegate web serving to Apache,  and it might be a more realistic longterm goal to deliver OpenACS that way.

I don't have any experience with mod_aolserver,  but I think Petru (who's doing some work on it?)  might be able to confirm or deny that combo as a possibility,  and gauge the effort required.

Also,  FWIW,  I am now uploading the Oasis VM v4.5 with beta code as of two weeks ago.  Sorry for the delay.

Well, if there are people building apps for their own personal needs, then you're probably right.

But for the consultant out there who is sick of trying to sell the benefits of Linux + PG to a Windows shop, being able to still use the code and the data model of OACS on Win + SQL Server is a Big Win.

Also, David's quite write. All it takes is one person to scratch an itch. Since DonB and the crew (including JBEllis, of course) have worked their asses off in building such a unique and exceptional system for supporting multiple DBs, the response to supporting SQL Server should be "Why not?" rather than "Why?"

(Of course, I'm ignoring the PITA factor. I figure that's DonB's problem. 😉)

talli

Correction for above.  "All our 'essential' systems run on some
variety of Unix, but our network..."

Also Apache 2 is a native Win32 app.  Can it talk to PG running inside Cygwin?

As far as supporting SQL Server ... does it have a sufficiently rich programming language to support our architecture?  One downside of aD's choice to bury so much logic in PL/SQL is that you need an RDBMS with good embedded programming language support.  PL/pgSQL was designed explicitly to give PG something similar to PL/SQL in capability.  If it weren't the ACS 4 port would've required rewriting big hunk of the toolkit as a first step.  We would've ended up with a lot more portable queries if we had but it would've taken even longer to get to where we are ...

Also supporting three RDBMSs is a somewhat intimidating notion.  We're already seeing time lags in support of new packages with just two RDBMSs.  Since Talli's involved in this discussion I'm compelled to remind him that Musea didn't port ETP to Oracle, Jon Griffin and I got stuck with that task.

A SQL Server veresion would almost certainly require some financial support from someone.  Win2K and SQL Server don't come with a "free for development" licensing model ala Oracle...

And if we complexify the project even further ... is it reasonable to expect anyone (much less me) to manage the project gratis?  This project has already taken up literally months of my time, income-free months, and while I've had success in landing OpenACS-based consulting work whenever I do the project suffers because I get pulled away from it.  If we make the project even more complex to run either more volunteer managers need to step up to the plate (this may be true even if we *don't* make it more complex) or we need to find some way to get me some subsistence funds.

On the other hand ... I stated in public many moons ago that if I were running aD, SQL Server - not PG - would be my choice as the next RDBMS to support after Oracle.  The commercial advantages are obvious even if the technical and organizational barriers are equally obvious.

Here's a first step for folks to take: do a technical evaluation of what it would take to port to SQL Server.  I'm talking queries and PL/[pg]SQL.  We did something like this for PG in the early times, marking out problems and coming up with solutions (hierarchical queries and the tree sortkey solution, for instance).

Without a detailed analysis of this sort we can't possibly begin to estimate the difficulty involved in doing a port.

For instance ... do they support the SQL standard outer join syntax as well as the old Sybase ("*=" etc) syntax?  If so, the potential work required to port queries just dropped significantly.

So on and so on ...

Just so everybody knows, I did start porting OpenACS to MSSQL Server last year. I took three weeks, and ported about 90% of the kernel using a translation program I wrote and some hand tweaking. The last 10% (triggers, non-standard cursor usage etc.) will probably take another 4 weeks or so, plus some weeks for regression testing.

If you want to check out the effort, including translated TSQL code, take a look here. Also, to see how I handled the different language issues, you can check out the side-by-side pg/tsql view

Todd, I am worried about the transaction handling and not supporting MVCC, but I think for a not-to-concurrent Intranet application you'd never really have to worry about it. For more serious initiatives, you might be looking at more serious investment in DBA time.

Don, to address the issue of keeping it up-to-date, I thought that using machine translation for ~ 85% of the work was vital. I wouldn't have bothered starting the port otherwise.

Also, while not the cleanest of code, this work will be reusable if someone wants DotLRN or whatever aD comes up with for Pg support to run on MSSQL Server.

This is enormously helpful. I realize that doing a Windows port would require some serious sponsorship of some sort. What I want to know is, assuming a sponsorship for the port, what would be the most efficient way to do it?

Let me try to sum up the options discussed so far.

First, the web server layer:

1. Use native AOLServer 3.x on Windows. Pros: It works now (sort of). Cons: You're stuck with legacy, because AOLServer 4 has no Windows support. (Nobody has yet said whether OACS will require AOLServer 4 in the near to medium-term future or what functionality one gives up by sticking with 3.x.)
2. Use AOLServer 4 on cygwin. Pros: The cygwin team does much of the hard work. Cons: Some stuff required for AOLServer has not been implemented on Cygwin, and getting the Oracle driver to work could be a really nasty job.
3. Fork the AOLServer code to develop a Windows-compatible version. Nobody has seriously mentioned this option, so I'm guessing it's a huge amount of work, both initially and ongoing.
4. Develop mod_AOLServer for Apache 2. Pros: You get all the cool stuff that comes with Apache. Cons: The initial port could be a lot of work (despite the existence of mod_AOLServer for Apache 1.3) and nobody really knows what the ultimate performance might look like.

Even assuming one of the above options is feasible, it sounds like there's the problem of the database. If I understand correctly, PostgreSQL only runs on Windows when compiled to cygwin, and there's some question as to how well it would work with a non-cygwin-based web server.

Porting to SQL Server might be an option. It would be a lot of work, and we don't fully know yet what would be hard. However, based on the work and knowledge of a few community members, it seems that SQL might support the necessary functions and that the maintenance effort could potentially be reduced to a manageable level through a certain amount of automated query translation.

Is this summary accurate? And if so, what would be the next logical steps for figuring out the best option?

libpq is available through the PosgreSQL Cygwin package, so you can compile against that for a C module (lipq++ for C++), or you can use ODBC or JDBC.

John's already done alot of the hardwork in porting to SQL Server. he's at least half of the way there. So supporting SQL Server is much easier and much closer on the horizon than either mod_nsd for Apache2 or building Windows functionality back into AOLserver.

I feel pretty confident that if you went into a window's shop and said that they could use SQL Server they would be much more comfortable about considering running AOLserver in cygwin. In cygwin, AFAIK, the sysadmin still needs to have some Unix experience. I don't see much gain if the admins are using Windows but still have to use Unix emulations to run the apps.

Even if SQL Server is 5 years behind, people in the Windows world don't know or don't care. They want to be able to use the administrative tools and buzzwords that they are comfortable with. SQL Server probably has all sorts of whiz bang apps that these admins would be pissed if they didn't have.

Don, as far as maintaining another RDBMS I agree it will add another degree of hassle. But even maintaining two DBs will be a hassle if we don't build tools to lessen the burden of developing for various systems. Tom Jackson and John Sequiera's tools that automagically deploy or convert code for multiple DBs are important steps.

talli

The *best* solution, from a marketing perspective, would be IIS. Windows shops like Windows products. If they're MSCE, then they've probably been taught how to "secure" that server, how it's better than the others, how to upgrade it, etc. However, trying to kludge the OACS into IIS would be painful.

Apache 2 has been built from the ground to be portable. The Apache Portable Runtime is a foundation layer which was developed to provide cross-platform deployment. From the benchmarks that I've heard about, it even outperforms IIS on a Windows box. Apache 2 has made really great strides in becoming a much better application and much less "patchy".

That being said, OACS uses the features in AOLserver extremely heavily. mod_nsd is basically a mimic of these features. Rob Mayoff, a wizard level AOLserver hacker, built the original mod_aolserver. Even then, I've never gotten the sense that it was anything other than a quick hack. There's *a lot* in AOLserver that would be really difficult to reproduce.

IMO, the best part of the OACS stack is AOLserver. So I'm probably not the right person to ask how it should be replaced, and I'm certainly not qualified to say which would be easier, getting AOLserver to work on Windows or to build mod_nsd into Apache 2.

But I think it would be a much bigger win to have mod_nsd as then people in the Unix world could take advantage of it as well.

As far as my comment about running cygwin, I think it will be distasteful to a Windows shop to run anything in Cygwin. From my experience trying to sell to Windows shops, they want native Windows apps.

Just imagine trying to get Linux shops to run Windows products under WINE. And then realize that Windows admins are usually far less experienced and qualified. IMO, it would be a disaster.

talli

I'm guessing it's a dearth of ISAPI skills. Technically it's certainly not a bad idea, but I think a cross-platform effort like Apache2/mod_aolserver offers more ROI. I also think that your typical Win32 IIS administrator is going to want to avoid ISAPI filters at all cost on their production servers. You're destabilizing a somewhat fragile piece of software (my experience coding for a web farm), and adding new potential security holes.

I also wanted to mention one thing Michael left off his recap list : in the event of going with a native Win32 database, you'd need to maintain the ODBC driver. I'm not sure how big an effort would be required since it's a pretty static spec, but it's something to keep in mind.

I think it comes down to a matter of niche. The important question is: Why do people want to install OpenACS on Windows anyway? In my case, I had a small site, no budget, and a machine that needed to do double-duty as a Windows workstation. Others want it for development work or a simple sales demo on a Windows laptop. (With VMWare a strong competitor for these uses.) And I imagine there is some market for rapidly deployed intranet or small non-profit sites. I could be wrong, but I can't believe anybody wants to run large e-commerce OpenACS sites on Windows.

Some sort of sponsored mod_aolserver or FastCGI solution could definitely benefit the entire community. Cleaning up, packaging, and documenting AOLserver on Win32 would just be much less work. Maybe use the saved time to create some new modules or improve some old ones? At any rate, I'm sure any work you can contribute will be warmly received. In addition to the good suggestions this thread is generating, you could try out the existing options (native AOLserver, mod_aolserver, ISAPI) over the course of a week or so and anything you learn would be useful.

I'm not the best person to answer Michael's question about AOLserver features in v4 vs. v3. According to an OpenNSD bboard posting by Scott Goodwin:
"AOLserver 4.x is more aggressive at optimizing conn performance, has a new comm API that is tremendously simplified, has virtual server capability put back in, plus more."
I'd guess new sites will increasingly use AOLserver 4, but I don't think you need to worry about AOLserver 3 becoming unusable in the near-to-medium future.

Talli's business environment may be different, though.

So a good AOLserver implementation under Windows shouldn't be any more difficult to keep running than Apache 2.0 under Windows.  Win2k when stressed out still seems to be less reliable than Linux when stressed out but it's no longer the kind of order-of-magnitude difference one used to see (I'm basing this on hearsay and third-party statements, not personally having experience trying to keep either NT or 2K servers running).

Of course giving your customer a pre-configured brand-new x86 box with Linux/AOLserver/OACS/PG would still cost less than a Win2K server license but for folks who like to spend money needlessly Win2K/AOLserver makes about as much sense as any other solution involving spending money needlessly ...

I think that on the issue of whether to port mod_nsd to Apache 2 or to implement FastCGI support, the latter would be a definite winner. Many people turn away when they hear about AOLserver but are definitely comfortable with Apache and/or IIS and besides there is just too much work to do on a working and reliable mod_nsd (not to mention the maintenance hurdle of keeping up with the AOLserver API).

Assuming that a FastCGI interface is written for AOLserver, I think the "appserver" AOLserver would best run under Cygwin (even though this means some work on Cygwin's pthread library).

Another note: right now I have no personal interest (or time :( )in mod_nsd or the FastCGI support, so unless someone pays me to do it, I'm not doing any work on them.