Forum OpenACS Development: Re: FYI: My Vision and priorities for OpenACS

Collapse
10: Re: FYI: My Vision and priorities for OpenACS (response to 1)
Posted by Barry Books on 01/31/04 02:53 PM
I think OpenACS is generally going in the right direction. The integration and installation is getting better. As part of 2 I'd like to see OpenACS move to xhtml and css stylesheets. WebDav could be huge combined with import/export.

As far as getting more people to adopt OpenACS I think the big sticking point is AOLServer. While it works great it's not Apache. I think many more people could run OpenACS if they could say we're going to run Apache, Postgres and some open source toolkit. TCL also seems to start religious wars, I'm not sure why I guess it's because it's better than Perl or PHP.

So without trying to start a fight would porting to Apache/mod_tcl help to increase awareness or be a great amount of work with no benefit?

Collapse
15: Re: FYI: My Vision and priorities for OpenACS (response to 10)
Posted by Andrew Piskorski on 01/31/04 05:06 PM
Barry, the perceived shortcomings of AOLserver vs. Apache have been discussed for years here in the Forums, and AFAIK the informed consensus has always been that AOLserver is here to stay - and for good reason.

Most importantly, while Lars didn't get into explicity detail about this in his vision and priority outline above, it should clearly follow from what he did say about what he thinks is important - which I agree with - that the whole AOLserver vs. Apache thing should not be a priority.

You really think AOLserver is "the" sticking point? You already touched on the Tcl vs. PHP issue... Let me tell you what I think: Replace AOLserver with Apache (lots of work for no technical gain at all), and will OpenACS get many more users and developers? No. In reality, what would happen is that yet another insurmountable "the" sticking point will arise. PHP vs. Tcl vs. Python vs. Perl, PostgreSQL vs. MySQL, etc. And in the end, maybe even ultimately the plain old "I don't care how good it is, it's not what XYZ already uses" sticking point.

What it all boils down to in the end is that OpenACS isn't LAMP, nor is it .Net, Java/J2EE, nor whatever other language/environment du-jour will next spark the fancy of the IT trade magazines and programming masses. And as long as it isn't one of those things, there will always be yet one more "the" sticking point "preventing" OpenACS adoption. Going down that road is playing to OpenACS's weaknesses, fighting a losing battle, and I don't see any sense to it.

Better to stick with the high-quality underlying tools OpenACS has now (AOLserver, Tcl, PostgreSQL, Oracle), and - more importantly - the sound technical and practical reasons for picking those tools in the first place.

Now, yes, there are a minority of people who really genuinely want to run OpenACS on Apache, or MS SQL Server, or whatever else. And the work John Sequeira and a few others have done towards those ends is laudable and good - and may even help in some of the external sysytems integration goals Lars touched on above - but it can't be the central focus of any OpenACS strategy - not any successful strategy anyway. Or so it all seems to me.

Of course, to partially contradict myself, if good support for Apache, PHP, Python, FastCGI, and whatever else just dropped into our laps, that would be great and maybe very valuable! (In fact in my Copious Free Time I've even thought a bit about working on AOLserver Tcl/PHP integration, just because it's interesting and potentially useful. Not quite so interesting and useful as integrating both AOLserver's database support C code and OpenACS's db_api into a Tcl library useable from outside AOLserver, but still...)

I just don't think any of that makes sense as a central focus, goal, or plan for the OpenACS project as whole. Make this stuff a subordinate goal, sure maybe, but please let's not convince ourselves that focusing principally on any one of these Apache vs. AOLserver religious-type issues would be a good strategy.