Forum OpenACS Q&A: Porting OpenACS (or ACS) to PHP ...

Posted by Johan Pretorius on 08/04/00 12:24 PM

Hi there,

I haven't done enough technical research to prevent me from getting
flamed for asking this, but here goes 😉

How about doing a PHP port of OpenACS? The enormous popularity of PHP
cannot be ignored, and it will also give the whole ACS/OpenACS effort
a lot more momentum. A PHP/PostgreSQL version of the ACS will make a
huge impact on the web!

2: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Todd Gillespie on 08/04/00 03:57 PM

How about doing a PHP port of OpenACS? The enormous popularity of PHP cannot be ignored

You would be suprised what can be ignored.

But seriously, here's an engineering answer: There are >250000 lines of code in ACS (source: pset 2. I'm not on a machine with GNU tools at the moment, I can't do a line count;). Porting them, and keeping them up-to-date would be non-trivial. It might be easier to add support for Tcl in PHP, and open the Tcl namespaces to the PHP environment, than to rewrite. But then what about the hypothetical people who start writing things in PHP on top of those interfaces?

Second problem is this: ACS is big on PL/SQL. To my mind, that is how it should be -- you should get as much work done inside the database as possible. But the unwashed masses, many of whom use MySQL and aren't even convinced of the needs of a real RDBMS, may differ. So they tend to write code implementing some segment of ACID way out in the webserver. Happy as I would be to have more people using ACS, dealing with more code like that would make me lose my morning bagel.

So although a port to a more popular language may attract more developers, I suspect that the real reason is that old demon, unwillingness to learn new tools.

and it will also give the whole ACS/OpenACS effort a lot more momentum. A PHP/PostgreSQL version of the ACS will make a huge impact on the web!

I think you misunderstand people's reasons for choosing a toolkit. So far, the only reason to choose ACS is if you _really_ want to run a community site, specifically a site that has community support worked into almost every component. Many many developers do not want/need that, at least not for what they are doing.

Now, do know at least one start-up in Mountain View who would like a PHP ACS, if only to access to a larger developer pool, but until they learn to work inside the DB, said programmers are still not useful.

Hope none of that was too inflammatory.
mmm.. bagels.

3: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Don Baccus on 08/04/00 07:51 PM

Todd's answer's a good one.

A more personal answer is that most of us who've done the work of porting the ACS to Postgres did so for one reason: so we can use it.

If someone's language bigotry is strong enough for them to want to port it to PHP, more power to them. No one's stopping them. But it's not on our agenda because OpenACS, as it stands, does what we want it to do - let us use the ACS on an Open Source database.

If our goal was to win popularity contests by providing an Open Source toolkit, we'd probably do something like PHP+MySQL. But we're not into popularity, we're into providing tools we can use with the least amount of effort we can get away with.

4: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Ben Adida on 08/04/00 08:20 PM

And to provide a somewhat more technical answer to your question. AOLserver Tcl/ADP is more flexible than PHP, which is very much tied to an HTML-like environment. AOLserver/Tcl is thread-safe and optimized for threaded execution, and while I don't know PHP's precise thread-safety status, I'm pretty sure it's not nearly as good as AOLserver/Tcl's. Finally, there's DB pooling and connection handling in general. The AOLserver/Tcl system is much cleaner and more efficient than PHP's weak pconnect() mechanism.

However, we are not opposed to a PHP port, as mentioned by other OpenACSers. If enough people are interested, they should definitely provide this port! I think it's a tough challenge, and may not be worth the trouble, but if it's worth it to someone else, we'll certainly link to it and applaud them for making OpenACS available to still more people.

It's just that no one on this team so far feels that the "I don't want to download AOLserver" excuse is a strong enough limitation that needs to be overcome. AOLserver is a solid, truly Open-Source product that more than meets our needs and can definitely meet the needs of any PHP programmer.

5: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Johan Pretorius on 08/05/00 08:38 AM

I hear you all loud and clear - thanks for the comments. The mere fact that the ACS is available on an opensource database is already one heck of an achievement 😉

Some trivia: I've already installed Oracle, AOLServer and classic ACS on my Linux (SuSE 6.4) box (development only). The next step would be to get OpenACS going. Hopefully I'll be able to offer some contribution to the OpenACS soon! But I first need to work through Tcl/Tk ...

6: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Don Baccus on 08/05/00 02:53 PM

Tcl's easy. Tk's a toolkit for GUI work, so you don't need to learn about it in order to understand or contribute to OpenACS.

Tcl/Tk's what pgaccess - the access-style front-end to Postgres - is written in, so if you're looking for an interesting program to study that uses Tcl/Tk you might check it out.

7: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Denny Shimkoski on 08/22/00 02:31 AM

I stumbled upon this earlier today...

http://tkphp.sourceforge.net/

recognize_the_data_model_p

'Your Workspace' and everything. I didn't see any credit given to the ACS on the site. Perhaps it is buried in the source?

8: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Adam Farkas on 08/22/00 02:52 AM

Imitation/flattery... but this is ridiculous! Call in the lawyers 😉

Seriously, though, I think this may be evidence for a latent market for an ACS port running on PHP.

I wouldn't say it's a high priority, but something to think about. Gotta keep an open mind.

9: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Richard Li on 08/22/00 03:00 AM

Yes, and the data models are for MySQL.

10: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Don Baccus on 08/22/00 03:11 AM

That's hilarious ...

Hey, quick, release 4.0! That'll bog him down :)

11: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Johan Pretorius on 08/22/00 07:24 AM

Me again - Using PHP is one thing, but mySQL! That is a scary thought ... And did you see the "Music to code by" section on the
Scourceforge page? <http://tkphp.sourceforge.net>

However, most of you should be aware of the new OpenTcl "movement" - details can be found here: http://216.167.121.111/opentcl/ (the site has been moved recently, hence the ip address).

The mission of the OpenTcl core team will be to:

1) Encourage a variety of different styles of Tcl usage

2) Stimulate the creation of new extensions and applications

3) Provide convenient packages of the Tcl core and/or extensions, to make it is easy as possible for people to get the functionality they need

4) Keep the core as simple as possible, so that people aren't required to use things they don't need or want

5) Allow Tcl to develop as rapidly as possible

6) Maintain the traditional high quality and stability of Tcl releases

7) Involve the Tcl community in as many ways as possible

<http://dev.scriptics.com/community/coreteam/>

12: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Janine Ohmer on 08/22/00 02:49 PM

A note about the ACS has now been added to the page. :)

13: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Nicholas Irving on 10/09/00 08:37 AM

Okay heres my two cents
AOLServer is a Web Server that has an TCL Interface.
PHP is a language that can be used on a wide number of web servers (AOLServer is one of them), thus making code portable across platforms.

There is a big initiative in ArsDigita to make ACS work on a large number of web servers, such as Apache, IIS and others, which means they have to reinvent the wheel as each server does not have the AOLServer API installed.

By doing a port in PHP, means that ACS and OpenACS can automatically be available for all web servers that PHP is supported for, and with the way PHP is going it will be available more widely than AOLServer.

Okay it will take a bit longer to port the API etc to PHP, but it seems a better way to do it than updating a number of AOLServer clones for each Operating System. Plus I know that the PHP community is a lot larger than AOLServers own, where I can get a response on a programming problem quicker and easier and without distain.

PHP wants to be supported and expand, AOL does not want this to happen, they still control a large amount of the source (although they will not admit it). Just take a look @ the Zend Optimizer (AOLServer has had this for a while) it was seen as necessary and it was developed to aid the speed of PHP. What has been the big development in AOLServer over the past couple of years?

14: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Roberto Mello on 10/09/00 01:16 PM

Nicholas,

Yes, PHP is popular and I thinks it's a fine tool. As others noted several times in this thread, if anyone wants to do an ACS port for PHP, we have no problem with that. We in the OpenACS project simply don't have the man power, nor a good reason to do so.

You can run the ACS on AOLserver, which was chosen way back in 1995 far its superb database capabilities. PHP+Apache, despite all their popularity still haven't gotten to where AOLserver was in 1995. As one of the PHP developers noted at the AOLserver list, PHP's threaded implementation still needs lots of work. Not to mention Apache's.

What was AOLserver's big development in the last couple of years? Maybe we should twist the question a little bit: What has been Apache+PHP's big development in the last couple of years that they still haven't matched AOLsever's capabilities that date of 1995?

You can also run ACS or OpenACS in Apache, thanks to mod_aolserver. Learning Tcl takes a day or less for a developer. Is that too much effort? Soon you'll be able to run ACS on IIS. That takes care of 89%+ of the webserver market.

The AOL team does want AOLserver to be supported. Improvement is being done in that area and we'll have a better aolserver.com website soon. AOL controls the official AOLserver release, but AOLserver is a GPL'd product so if anyone wants to fork another project, they can, but nobody has found a good reason to yet.

I think Apache and PHP are great tools, as is AOLserver, but I haven't seen a toolkit for PHP like the ACS yet. Porting and maintaining to PHP would be a big effort, and mostly unnecessary.

15: PHP and portability. (And a note about ACS 4 porting) (response to 1)

Posted by Lamar Owen on 10/09/00 01:52 PM

Well, having done a bit of php work now (for hire), I feel I can comment on this.

PHP's database API's are not anywhere near as orthogonal as AOLserver's -- one API for MySQL, one API for Oracle, a different API for PostgreSQL. Porting between databases is hard enough as it is -- PHP makes that part much harder.

Although, with ACS 4 this is going to be true with ACS Classic versus OpenACS, too -- unless the OpenACS databases drivers (when more than one exists) 'emulate' the ns_ora call 😊. Which is a big gripe for me -- we'll see how well the new bind variable API stands up to porting, and how the proposed new AOLserver 4 DB API fits in with the ACS 4 API.

aD has basically invented a new DB API for AOLserver under the guise of ns_ora, making it more difficult to port.

I'm looking at the postgres driver now to see about bind variable support (and ns_ora emulation to ease porting), and it appears to be not too difficult, but not too easy, either. It's just putting logic from the tcl code to the C code, in reality.

So, rewritten tcl for the core db API procs may be easier in both the short and long runs -- just how many DB API's support bind variables anyway? A version of the core DB procs for a non-bind-variable database, properly modularized, might help with the porting of ACS 4 to all databases -- bind variable emulation in the drivers might defeat easy porting, unless that code is written in a database-agnostic manner to be easily pulled out of the pg driver and plugged into another driver.

16: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by David Eison on 10/09/00 04:38 PM

Nicholas, we're doing the Java port to address all the concerns you brought up about PHP.
Simple practical matter:
A) Customers aren't demanding PHP. They are demanding Java.
B) It's not clear that switching scripting languages gains you much, while switching to Java might win stuff (compiling implies speed; better possibilities for integration with other apps beyond "well, that data's in Oracle"; possible wins from having class structure, etc.)

So anyway, I think the real worthwhile comparison would be PHP port vs. Java port. It looks to me like if you have a Java port, then all the arguments for PHP go away, and I'd like someone to correct me if I'm wrong there. :)

17: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Marshall Trammell,III on 10/20/00 12:52 AM

Roberto writes: 'we will soon be able to run the acs on IIS.'

1) When?
2) What would a web hosting company have to provide?
Oracle would be too expensive.
3) Is there a service provider that has an IIS/ACS solution now?

18: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Roberto Mello on 10/20/00 01:06 AM

1) Now. Go to http://www.arsdigita.com/download and grab the IIS module.

2) Same things as if you were using any other webserver.

3) I haven't heard.

19: Response to Porting OpenACS (or ACS) to PHP ... (response to 1)

Posted by Mark S on 11/28/00 02:56 PM

2) What would a web hosting company have to provide? Oracle would be too expensive.

You might check out http://www.scorpions.net/web/oracle/ora_all.html