Forum OpenACS Q&A: Re: Windows Installer ready with OpenACS, dotLrn and Project/Open

Frank, presumably because Dossy is busy doing other higher priority things? I'd say installing all of OpenACS and Project Open on Windows, just to check whether they actually work with the latest AOLserver code is, uh, more a job for the OpenACS and Project Open developers, and/or the auto-magic Windows Insaller maintainer, than it is for the AOLserver maintainer.

More importantly, any "Windows Installer" is doomed to be eternally out of date - and thus not particularly useful - until and unless the AOLserver build process on Windows (the lack there of!) is dramatically improved. Right now, building both the core and a bunch of modules on Unix is fairly easy, but building on Windows has only very limited support and is thus a major PITA. (Which is still a lot better than it used to be, note. Dossy's Windows Tcl build script for the AOLserver core is a very useful prototype.)

Creating a spiffy Windows installer using years-old binaries, but having no useful way to update and recompile all that code, seems very much putting the cart before the horse...

One of these days I may work on such a Windows build process, (likely experimenting with "bras", the Tcl-based make replacement), but as I currently only use the AOLserver core plus nsopenssl on Windows, I don't have any immediate plans to do so. And maybe Dossy or someone else will beat me to it.

If all you want is recent Windows binaries for Tcl, the AOLserver core, or nsopenssl, I can just send you those. I'm currently using slightly out of date versions of everything (Tcl 8.4.7, AOLserver 4.0.8, and nsopenssl 3.0 beta 23), but I'll probably be upgrading to the latest releases of everything in a few weeks.

Hi Andrew,

thanks for the reply.

> installing all of OpenACS and Project Open on Windows,
> just to check whether they actually work

It's the oposite way from our (P/O) perspective: OpenACS inc. PostgreSQL is installed in <10 minutes, so that really shouldn't be an important effort for anybody. I'm only talking about OpenACS. P/O's requirements are uncritical.

The benefit of such an installation is that the AOLServer developers would get an integrated testing environment. They wouldn't have to rely on other persons to report errors but simpley would need to start the OpenACS _installation_ procedure to get a 70% test coverage.

The errors that stopped us were really basic and could probably be resolved by an AOLServer developer probably within minutes.

Concerning the build process: This was a _real_ pain for us. 4.0.beta10 is working more or less satisfactory for us, imagine..., so we're never going to touch this anymore.

I believe that OpenACS + AOLServer has a _huge_ (OSS-) market potential if it would be easier to install, particularly on Win32. But our organizational issues have inhibited this already since several years. Maybe we can finally break this ice.

> any "Windows Installer" is doomed to be eternally
> out of date

There is one fact that is probably difficult to swallow for a developer: That even an old version of AOLServer is doing the job. We're still using 3.3oacs on our Linux production environments and I've got _no_ intention to change until I see a major benefit. And a similar situation holds for Win32 with the addition that binary releases are easier on Win32 then on Linux because of a more coherent system environment.

So I would disagree with you on this point. Being "out of date" is not even relevant from a users point of view. AOLServer is very stable in general so a new binary "dumb-user" release every 6 months would be more then sufficient...

However disagreeing, we all have the same objective: Promoting AOLServer + Openacs.

Bests,
Frank