Home
The Toolkit for Online Communities
17243 Community Members, 2 members online, 2111 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Windows, AOLServer, and OACS

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

Icon of envelope Request notifications

Collapse
Posted by Michael Feldstein on
I'm trying to wrap my head around the situation for OACS on
Windows in the short to intermediate term. Here's my current
understanding:

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

Collapse
Posted by C. R. Oldham on
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.

No, I think they actively removed Windows support at version 4; I seem to remember seeing that in a changelog entry from SourceForge

Several people have gotten OACS to run on Windows, but not well.

It was stable enough for me only for development. I discovered VMWare (thanks to John Sequeira) and never looked back.

Note there was been some discussion here about compiling late versions of nsd under the Cygwin toolset. That could work, but if one needs to use Oracle, getting the Oracle driver stable under Cygwin might be quite an effort.

Collapse
Posted by Michael Feldstein on
Even assuming you could deal with the driver problem, how
much of a performance hit would you take from cygwin? Would it
be acceptible enough to run a production server that way?
Collapse
Posted by Jonathan Ellis on
if there's a performance hit to running postgresql under cygwin, I haven't noticed it.  I don't know why nsd would be any worse.
Collapse
Posted by Jamie Rasmussen on
I've gotten OpenACS to run on Windows reasonably well, and it was not an insignificant effort. Check out my installation documentation. I use PostgreSQL 7.1.3 on Cygwin on a modified version of AOLserver 4b1. The document isn't quite done, but a finished version should be up in another week. (Revising with PostgreSQL 7.2 information among other fixes.) My site is pretty small but I am using ImageMagick, form-based uploads, and some other moderately complex things. That document also explains why I couldn't get AOLserver to compile with Cygwin. The site is stable enough for my purposes even with an early beta of AOLserver 4, which works better for me than the last official release for Windows did. There are bugfixes and backports that would be nice, but that I won't get around to soon.

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.

Collapse
Posted by Roberto Mello on
The AOL team that handles AOLserver removed windows specific stuff from the code because it made the AOLserver code worse and harder to debug, and they don't run anything on windows. I don't know the nitty-gritty, but there were significant technical issues that were discussed on the lists and on the AOLserver chatroom.

Now that doesn't stop people from modifying it to work on windows. I think acs-misc.sourceforge.net has Windows versions.

Regarding cygwin, I know a lot of people that run PostgreSQL and other unix apps in production under cygwin and they seem to be very happy. I've never made any tests, but I don't _think_ the performance hit is significant. Having more maintainable, more stable code is certainly a good thing if the trade-off in speed is not big.

Having a windows installer would be really nice. I toyed with the idea of creating a windows installer for PostgreSQL and then later OpenACS. Problem is that I never find myself using windows much, so I never got around to doing it. But it would be nice.

Does anybody know what are (if there are any) licensing issues of using the Microsoft installer thingy (.msi?) with GPL'd applications?

Collapse
Posted by John Sequeira on
Michael,

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.

Collapse
Posted by Talli Somekh on
I agree with John that the best approach is probably to get mod_nsd/mod_aolserver to run with Apache 2.0. This means getting some serious energy behind whoever chooses to give this a run.

But then, I wonder if the more interesting port for Windows is to make OACS available on SQL Server. I think it would be much more attractive to windows shops if they could maintain a native DB in an enviro that they are familiar with rather than using a DB with a different procedural language that is also running in a unix emulation.

talli

Collapse
Posted by Jonathan Ellis on
if they are running SQL Server I'd bet the odds they're not also coding with .NET are slim...
Collapse
Posted by Talli Somekh on
Jonathon Ellis said: "if they are running SQL Server I'd bet the odds they're not also coding with .NET are slim..."

If they are using Windows, the odds they are not using .NET are slim. But I know that there are many people in this community that would really like to be able to use a combo of AOLserver/Apache, SQL Server and OACS.

talli

Collapse
Posted by Jonathan Ellis on
If they're already "in the community," presumably using PG isn't an ideological hurdle, and since PG under cygwin is pretty much a point-and-click install, I really don't see a Big Win here.
Collapse
Posted by David Walker on
Presumably the person(s) doing the porting will be the ones that see the advantages of it. From my perspective the Oracle version is pretty useless but there's a number of people that need it and will use it.

All it takes is one person or group that thinks it is important enough to do.
Collapse
Posted by Talli Somekh on
Jonathon Ellis said: "If they're already "in the community," presumably using PG isn't an ideological hurdle, and since PG under cygwin is pretty much a point-and-click install, I really don't see a Big Win here."

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

Collapse
Posted by James Harris on
I agree with Talli.  I work at an Australian university.  All our
'essential' systems (financial accounts, payroll, enrolment, and
the like), but our network is moving towards a MS domain model.
There are a lot of new boxen running Win2K advanced server /
SQL server / IIS.  It would be a lot more feasible to attempt to
introduce OpenACS if it worked with mod_aolserver (for IIS or
Apache) and SQLServer.
Collapse
Posted by James Harris on
Whoops.

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

Collapse
Posted by Jamie Rasmussen on
I think having a fast, easy, reliable, out-of-the-box system for Windows could be very beneficial to the OpenACS community. Lots of people just need basic bboard functionality, or just want a simple ticket-tracker for their nightly tarballs. And some of the engineering that could be done for Windows would also give Unix users more flexibility.

If you were installing today, native AOLserver is the best option. (Really the only option.) But there are several possibilities in the short term. To my knowledge, nobody is actually working on AOLserver 4 on Cygwin. The problem is that AOLserver uses some functions that have not been implemented in Cygwin yet. For example, pthread_rwlock_* and sigwait. The LGPL Win32 pthread library at http://sources.redhat.com/pthreads-win32/ supports these things so I think it is only a matter of time until Cygwin does. With Cygwin, the OS choice would be almost completely transparent to OpenACS package developers. There might be some minor performance hit, and it might be difficult to configure with a native Windows RDBMS.

mod_aolserver on Apache 2.0 seems like it might be the most "bang for your buck". It should be relatively easy to maintain. It might be slightly harder to write portable package code than with Cygwin, but not much I think. And though it hasn't been tested with Apache 2.0, the existing work should provide a good starting point.

I've only used SQL Server a bit, but wouldn't it be a huge effort to add support for another DB? Porting all of the existing queries, keeping all of the packages synchronized on the various platforms, testing new code on another DB, yet another set of installation/configuration decisions and documentation, ... It seems to me that lack of database choice isn't what is keeping people from using OpenACS on Windows, it's lack of web server choice. If the Apache module worked cross-platform it would also be quite useful to the Unix community.

Switching gears to Windows installers, the standard Cygwin installer already includes PostgreSQL. The main problem I found was a lack of clear instructions. Once you figure out what to do, the actual installation is quite pleasant. At least compared to Oracle. Installing AOLserver is the only step that could really use a good installer at this point. The problem right now isn't that installation is that complicated, just that the necessary correct files, when they exist, are distributed throughout the web in many separate confusing versions.

I don't think an installer for OpenACS files would be very useful, except for showing which packages are known to work on Windows and what their dependencies are. It wouldn't be worth the effort given how quickly files in OpenACS do (and should) get updated. Rather than having an installer, how about a web page for every available package that includes, among other relevant information, whether or not it works on Windows.

There's no problem using Windows Installer (.MSI) files to distribute GPL'd applications. ActiveState uses it to distribute Perl. A MSI installer requires someone with the time, knowledge, and interest to maintain it, who is also willing to spend $1000 for a tool like Wise for Windows Installer. Another option is NSIS, the installer system for Winamp. It isn't standard, but it is open source.

Collapse
Posted by Don Baccus on
Apparently the module API for Apache 2 is considerably different than for Apache 1, which is why module porting of even things much more mainstream than mod_aolserver has lagged.  This is my understanding, anyway.  So porting mod_aolserver may be a considerable amount of work.

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

Collapse
Posted by Todd Gillespie on
Don: SQL Server uses the ANSI JOIN syntax as of (IIRC) version 7, which is about 3? years old. Moreover, all the MS docs focus on the ANSI syntax instead of the Sybase hack, so that development community is used to it.

MSSQL has a ...um.. "language" of a sorts, but I wouldn't want to use it, T-SQL. Much as Rolf described PHP, T-SQL combines the worst features of several languages. OTOH, there are no doubt improvements since I last tangled with that beast, but I cannot describe such.

MSSQL has a number of small differences that can be papered over, for instance, there are no sequences, but you can create a table with an '@@IDENTITY' type for key generation.

MSSQL has no syntax for transative closures.

MSSQL, when I last saw it, has no MVCC, and they were pretty fierce about knocking any kind of optimistic locking. So a port to MSSQL will have many more opportunities for deadlocking.

In summary, most of the largest issues in an Oracle-to-MSSQL port have been solved in the Oracle-to-Postgres port. There are new issues, of course, but this is well within reach. The problem, of course, is financing.

More on Apache2 when I have more to report.

Collapse
Posted by John Sequeira on
Hey - I've started the MSSQL port!

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.

Collapse
Posted by John Sequeira on
I should mention I'm not pushing the SQL Server port forward right now because I'm too short on free time.  OTOH,  payed time could be found :-)
Collapse
Posted by Michael Feldstein on

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?

Collapse
Posted by Michael Feldstein on
Oops. Let me modify my post a bit. It seems I dismissed the
"fork AOLServer" option a bit too quickly, having missed Jamie's
post (although I guess "fork" might be too strong a word).
Collapse
Posted by Roberto Mello on
I don't see any reason to why PostgreSQL on cygwin would have any trouble working with non-cygwin applications. I know of several people that run Visual Basic/Delphi applications accessing PostgreSQL on cygwin on production systems.

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.

Collapse
Posted by Jonathan Ellis on
I don't have any trouble accessing PG/cygwin from nsd/noncygwin, either.
Collapse
Posted by Talli Somekh on
Michael Feldstein wrote: "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."

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

Collapse
Posted by Michael Feldstein on

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.

Talli, I'm not quite following you here. In your first sentence, you seem to be saying that SQL Server + AOLServer/cygwin would sell in the Windows world. But in your second and third sentences, you seem to say that AOLServer/cygwin would not sell well in the Windows world because it would still require Unix sysadmin skills.

Leaving aside the question of SQL Server for the moment, which web server solution are you advocating as the best approach to having a viable (and marketable) Windows-based solution?

Collapse
Posted by Talli Somekh on
Michael Feldstein asked: "Leaving aside the question of SQL Server for the moment, which web server solution are you advocating as the best approach to having a viable (and marketable) Windows-based solution?"

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

Collapse
Posted by Guan Yang on
Why hasn't anyone considered using the AOLserver ISAPI filter?
Collapse
Posted by John Sequeira on
Guan,

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.

Collapse
Posted by Michael Feldstein on
Thanks for catching the omission, John.

And speaking of omissions (and ISAPI), I forgot to list the
FastCGI option
(http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001
uK&topic_id=11&topic=OpenACS). It would work both with
IIS/ISAPI (http://www.caraveo.com/fastcgi/) and Apache
(http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html),
although mod_fastcgi for Apache 2.0 isn't complete yet. What are
the pros and cons of this approach? And would they have the
same stability issues on IIS that John lists for the pure ISAPI filter
approach?

Collapse
Posted by Jamie Rasmussen on
John's automatic translation work is cool and could be useful. But I still don't think the database layer is keeping Windows users away from OpenACS. OpenACS already supports a scaleable, native, expensive, proprietary database that Windows shops have a lot of experience managing. On the other hand, there is currently no easy/good solution for the web server layer. According to the last Netcraft survey, a few thousand sites were running AOLserver, about 13 million were running IIS, and over 20 million were running Apache. Even though the percentage of Apache sites running on Windows must be rather small, there are probably more skilled Apache-on-Windows admins than people who have even heard of AOLserver. And of the small AOLserver community, only a small percentage of folks have tried and care about the Windows version.

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.

Collapse
Posted by Don Baccus on
Someone should ping Yon Derek about this.  I have VS for C++ but I only have Win98, so even if I had the time to play with AOLserver on Win32 I don't have a proper development box (it sounds like thread support issues make Win98 an inappropriate platform even for testing).

One note about John's work, it doesn't sound to me as though he's "mostly done" with a port, he's made good progress on the *core*, which is just a slice of the necessary work.  Having automated tools do much of the work is a win, of course, it helped a lot with the PG port.  But we were still left with a ton of work to do.

I still think folks trivialize the effort needed to manage and maintain a project supporting three RDBMSs that implement fairly divergent forms of SQL.  I'm concerned about the implications for futher development of the toolkit.  Big chunks of it are frankly lame and need lots of work, and diffusing our resources on a port to a third RDBMS at this time doesn't seem like the wisest thing to do.

I know Michael's interest is largely with dotLRN, and that he deals with large financial companies among other things.  Is Oracle a large barrier of entry in the spaces you're interested in, Michael?  Price is an issue but we do have a twin-pronged solution to offer.

Collapse
Posted by Michael Feldstein on
In my world at least, lack of SQL Server support is not a huge
deal. Lots of places do have Oracle and, assuming PostgreSQL
is a viable option for a Windows-based solution, I don't see this
as being a huge problem--particularly if PostgreSQL could come
bundled in some kind of unified dotLRN installer.

Talli's business environment may be different, though.

Collapse
Posted by Michael Feldstein on

Jamie wrote:

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.

Is this the consensus? Also, how much of an ease-of-use problem is there for Windows sysadmins running AOLServer? I understand that it's Unixy, but how much would a Windows sysadmin have to learn to keep a reasonably large dotLRN installation (say, 10,000 users and 250 classes) up and running reliably? And how does that learning curve compare to the same sysadmin running mod_aolserver on Apache?

Collapse
Posted by Don Baccus on
Under Unix/Linux, once set up neither AOLserver nor Apache require much in the way of babysitting as long as you're not overloading the box to the point where it starts to melt.  I know photo.net's struggling a bit on x86/Linux but it's way up in the high percentile range of traffic.

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

Collapse
Posted by John Sequeira on
Don,

In case I wasn't clear,  I'm guessing I have ~4 weeks to go *on the openacs kernel data model*.  So you're definitely correct,  that's a far cry from completing an OpenACS port.  I would expect to need some help on the database driver,  the request processor, etc.  and that once that was taken care of,  other modules could be ported on an as-needed (or as-funded) basis.

I don't think it's a great goal to get MSSQL server supported on the same level as Postgres/Oracle,  and it wasn't mine.  I agree that it would be a distraction,  and frankly I'd rather see the base platform get better as well.

Having said that,  I think that having _something_ that shops with strong MS dependencies (particular on the DB level) could consider is worthwhile.  There are many good ideas in OpenACS that could be used independent of the entire platform,  and I think that the data model encapsulates many of them.  There is a big difference between full support for MSSQL Server and what one might think of as "bullet-point" or tentative support.  In that gap I think there's room for a project that would be useful in spreading the word,  and gaining the full supported platforms more converts.

Collapse
Posted by Petru Paler on

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.

Collapse
Posted by Don Baccus on
Thanks for the clarification on your progress, John.  A full port would represent several hacker-months, then, based on your progress thus far.

That makes sense...

Collapse
Posted by Michael Feldstein on
Petru, do you have any knowledge of how a FastCGI approach
would perform relative to taking the mod_ approach on Apache
2.0?
Collapse
Posted by Petru Paler on
Petru, do you have any knowledge of how a FastCGI approach would perform relative to taking the mod_ approach on Apache 2.0?

I suppose that a "perfectly" implemented mod_nsd would be the top performer. However, I expect the overhead introduced by FastCGI to be quite small and well worth considering development and maintenance time.

I also seem to remember some benchmarks from Zeus, where the Zeus web server talking to PHP over FastCGI was faster than native Apache+PHP.