Forum OpenACS Q&A: Watch Don toss bone to Win32 lovers

Posted by Don Baccus on 05/10/02 07:43 PM

A Japanese group has accomplished a native port of PostgreSQL for windows. No Cygwin. It's PG 7.1.3. There's currently a lengthy discussion underway on the PG Hacker's list regarding the issue of providing a native Windows version, and this site came up. In addition another company has done a native port - apparently providing a solution which almost perfectly parallels the Japanese solution, with neither knowing of the other's work - but isn't ready to release it. They have "thousands" of PG regression tests to run and expect a mid-June release. They say that performance under Windows appears to be excellent. The person from the company who's posting has also downloaded the Japanese effort and says it looks good.

The Japanese effort's open source and downloadable. Don't know the license status of the second effort.

If it were April 1st I'd add "and they'll be done with AOLserver next week" but ... nope. Sorry!

2: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/10/02 09:38 PM

This is very good news.

Just today I was mulling over the AOLServer problem again.
Check me on this, but isn't it the case that FastCGI, by itself,
would not solve the Windows problem? You could use it to
connect AOLServer to a windows-compatible web server, but
you'd still need a Unix box on which to run AOLServer...right?

If so, then mod_AOLServer is the most likely candidate here.
Can anyone here suggest a sensible (and preferably small)
subset of mod_AOLServer functionality that could would make
sense as a performance test case?

3: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Don Baccus on 05/10/02 10:40 PM

I knew Michael would be the first to respond!

4: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/10/02 11:25 PM

I knew Michael would be the first to respond!

I had to. It's my job.

5: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Jonathan Ellis on 05/13/02 06:15 AM

I think the fastcgi speculation was that it might be easier to maintain a fastcgi-enabled windows binary providing nsd functionality than an actual standalone nsd.

6: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by John Sequeira on 05/13/02 01:46 PM

Not just easier to maintain on Win32, but IIRC easier to support the many front-end web servers that people use on both *nix and Windows. Netscape/Apache/IIS all support FastCGI, and there's a Java module as well (which would presumably play well with the app server crowd).

Ultimately, you could replace mod_aolserver and the isapi filter with this code-base.

7: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/13/02 01:52 PM

Sorry if I'm a little slow on this, but is the idea basically to create
something like mod_AOLServer, only using the FastCGI
interface insteady of the Apache-specific mod_ interface? You're
still forced to replicate the AOLServer API in separate code either
way, yes?

8: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by John Sequeira on 05/13/02 09:51 PM

I have a question that might help me answer Michael's:

What's the difference between FastCGI and mod_proxy (or a proxy approach in general)?

Is FastCGI just a way of getting mod_proxy-like support into IIS?

9: FastCGI and mod_proxy (response to 1)

Posted by Petru Paler on 05/15/02 02:21 PM

is the idea basically to create something like mod_AOLServer, only using the FastCGI interface insteady of the Apache-specific mod_ interface? You're still forced to replicate the AOLServer API in separate code either way, yes?

Nope, you don't need to duplicate any code... what the FastCGI approach would do is put a FastCGI server interface into AOLserver, thus allowing any web server which has a FastCGI client to talk to it. So Apache would be just passing the request on to AOLserver that processes it and returns the page data. Apache is just a proxy -- which brings us to:

What's the difference between FastCGI and mod_proxy (or a proxy approach in general)? Is FastCGI just a way of getting mod_proxy-like support into IIS?

I never thought about it this way, but yes, this is exactly it. Come to think of it, you don't need FastCGI at all for "Apache integration" since mod_proxy does the same job! One has to wonder though, what does apache integration mean... if you want the actual tcl code to be executed by apache, then you need mod_nsd.

10: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/15/02 06:02 PM

Forgive me for being dense, Petru, but isn't it also the case that
AOLServer 4 would have to be run on a Unix-based machine,
with or without mod_proxy, FastCGI, or whatever? So going
forward, wouldn't you have to duplicate the AOLServer API if you
want an all-Windows solution?

11: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by John Sequeira on 05/15/02 06:34 PM

Yes - Michael. If your goal was to maintain compatibility with the latest and greatest AOLServer implementation, then you'll have to maintain a Win32 port no matter how it connects to IIS.

If the goal is just to have a Windows-only version of OpenACS,
then the shortest path would be maintaining an existing 3.x version of AOLServer that supported Windows, and backporting whatever AOLServer functionality OpenACS requires.

If an IIS front-end was a requirement, then maintaining the aolserver isapi filter with this version of AOLServer is also probably the easiest way to go (though not necessarily easy.)

12: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/15/02 08:03 PM

Thanks, John. It's not clear to me how important it is to maintaine
compatibility with the latest and greatest AOLServer, since
nobody seems to be able to tell me what will be in 4.x, how
important the new features will be, or when it will be out. (I'm
beginning to suspect that only AOL knows, if anybody knows at
all at this point.)

Whether it's important to run through IIS depends a great deal (I
think) on just how much we can get dotLRN to look like an
stand-alone, easy-to-install, easy-to-maintain package. If people
who want to use it can usefully think of it as a whole, unified app
instead of AOLServer + OpenACS + some stuff on top of
OpenACS, then I don't see IIS compatibility as very important.

13: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Jamie Rasmussen on 05/16/02 11:27 AM

nobody seems to be able to tell me what will be in 4.x, how important the new features will be, or when it will be out.

I would try emailing the AOLserver list with that question. My opinion is that it would be easier to maintain a native Windows branch from the early AOLserver 4 beta. Back porting bug fixes and new modules would be easier, and my experience has been that the 4 beta is more stable on Windows than the recent 3.x versions. My OpenACS 4.5 Win32 box is now http://empoweringminds.mle.ie/ so the installation doc I was working on is at http://empoweringminds.mle.ie/documents/one-doc?id=1.

In terms of making installations easier, I would like to create an MSI installer for the work that I've done. I will be using PerlMSI, which is part of ActiveState's Perl Dev Kit. Someone could do the same thing for a native PostgreSQL port, but I'm not volunteering. 😊 PostgreSQL on Cygwin already installs easily. AOLserver 3.x did have an installer, but since you had to patch the sources to make OpenACS work anyway it wasn't very useful.

14: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Don Baccus on 05/16/02 12:11 PM

Everyone should pay close attention to what Jamie's saying. At least what I think he's saying ...

Which is that he's got AOLserver already working natively under Windows. If he builds an installer, too ... watch out, folks, your dreams have come true. We're gonna make you do something with your dreams, Michael!

Now it appears that the PG group isn't very interested in a native Windows port after all, being satisfied with the Cygwin version because it seems to work well. The problem with native Windows ports is that those who've gotten it to work have had to chop things up a bit, adding a lot of conditional code in quite a few areas. This makes maintainability an issue. Some folks have made easier-to-install packages of PG/Cygwin but as Jamie says it's not really difficult to install.

The technical problem with Windows is that they don't support a lightweight process creation mechanism (ala what in some unices in the dim past was vfork). Since PG depends on process creation rather than threads this is a hassle. There are other issues, too, but this seemed to be the big one.

I only followed the discussion sporadically as it was getting a couple dozen posts a day at its height, so don't take my word as gospel truth. Read the PG hacker archives if you care deeply.

But Jamie's good news makes up for the PG news, no?

15: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Don Baccus on 05/16/02 12:16 PM

Here's a "deep link" to an information page at the site Jamie's implemented. It not only describes the service architecture (AOLserver, woo-hoo!) but has one of the best-written one-paragraph pitches for Open Source in schools that I've seen anywhere.

Good job, Jamie!

16: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Jamie Rasmussen on 05/16/02 01:56 PM

Thanks very much! Though in the future, please direct all visitors to my unattractive homepage, as I need the advertising revenue. Just kidding. And you give me too much credit; I've been building on a lot of other people's hard work.

If you need a native database, Oracle works well on Windows. It just isn't very compatible with elementary school budgets. I use the native psql client and pgAdmin II for administration, and have been very satisfied with PostgreSQL. But I have far fewer users than Michael was talking about for a dotLRN installation. One of the recent pg-hacker messages was about PostgreSQL performance on Cygwin. http://archives.postgresql.org/pgsql-hackers/2002-05/msg00532.php

There were problems with AOLserver on Windows in every version I tested. I applied some of the bug fixes on SourceForge for ADP parsing etc. and had to make some modifications for file upload to work. There are other problems that I haven't bothered to go searching for, but I believe they are mostly minor or easily worked around.

OpenACS will never run as well on Windows as it does on Linux. But it works well enough for small projects. I just put up an internal bboard for our corporate intranet, and the whole thing only took me about three hours, with most of that spent getting ADSI authentication to our Windows domain working.

17: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Don Baccus on 05/16/02 04:06 PM

Well ... Michael works in a market where dotLRN might well be deployed as the base for an intranet (or be used to build such a thing), so they wouldn't necessarily have a traffic load that Win32+OACS 4 couldn't handle.

And if a company accepted OACS 4.5 and liked what they were getting, and were faced with performance and reliability issues, they might be more open to a Unix-based upgrade than they would be when Michael first sticks his foot through the barely-opened door to make his pitch.

I'm sure there are others in the same boat. Getting in the door will be much easier with a Windows-based solution, many of the clients won't be overwhelmingly large in terms of heavy use, and once they're sold and trusting the team and technology, they may trust further technical recommendations. At least the odds would be a lot higher than when in the initial sales situation.

18: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Jamie Rasmussen on 05/16/02 06:04 PM

I completely agree with you, Don. I think this will become even more important as a selling point as the community develops other "vertical applications". Especially since the OpenACS core itself has almost no platform dependencies.

I won't be able to start work on an installer for the next week or two. I would definitely like help testing and documenting once I do. (Maybe I can set up an instance of bug-tracker!) I would especially be interested in the results when using Oracle, which I no longer have room on my dev machine for.

19: Response to Watch Don toss bone to Win32 lovers (response to 1)

Posted by Michael Feldstein on 05/17/02 05:05 PM

Yeah, Don's on the money. We don't need OpenACS and the
vertical apps built on it to run as well on Windows as it does on
Unix; we just need it to run well enough (and with little enough
care and feeding) that organizations can give it a test drive or use
it in small-site production situations with acceptibly low risk.

If Jamie's work gives us Windows compatibility for AOLServer 4,
and if Postgres/Cygwin runs OK for use on sites with low to
moderate traffic, then we've got something here.