Forum OpenACS Q&A: Response to PostgreSQL vs Interbase- Future Direction of OpenACS?
Unfortunately I don't really qualify for a "welcome aboard" as not likely to contribute much useful code but only some thoughts based on browsing around lots of different projects. Hopefully at least some of that may be useful as "cross fertilization" for people who are actually doing the hard stuff. I'm sure what isn't useful will just be rejected anyway 😉
1. Re XML inside Postgresql or outside. Agree that it can be done either way. The interesting thing is that it looks (to me, from outside) as though it can be done so easily inside Postgresql (without even getting right inside) that an equivalent to the Oracle XML facility should be almost trivial for people who have been getting right inside (combined with people who have built XML parsers etc). Your description of the gap between Postgresql team concerns and current developments on the web seems a plausible explanation of why, if it is that easy, it might not have been done. Adds weight to my suggestion that it could be higher on OpenACS priorities than Postgresql priorities (as well as higher on OpenACS priorities than ACS classic priorities since Oracle already has it).
As has been pointed out (with some vehemence) elsewhere, many people doing interesting and useful things on the web haven't got a clue as to why one would need ACID transactions. This is probably true of much of the XML community. So OpenACS might well be the most logical place for an initiative to bring Postgresql people and XML people together on this, as it SHOULD be very high on OpenACS priorities. Unless I've misunderstood the ORDBMS concept it should be a perfect demonstration of Postgresql's advantages so really important to them too once the relevance is made clear. XML integration is far closer to the non-web related ORDBMS stuff Postgres was originally developed for than any of the "conventional" SQL stuff it is actually being used for. So it could be more interesting to them if their attention was drawn to it.
2) Re using XML between the database and application, whether or not inside the database. This is becoming pretty standard. Even Microsoft is recommending it in preference to their own proprietary ADO "databinding" and adapting the latter to XML.
A point not mentioned in stuff I've seen here re XML so far is that it will soon also be pretty standard for actual delivery to the browser. IE5 has already overtaken IE4 and Netscape is emphasizing that their next release is more standards compliant than IE4. So the majority of browsers will soon have proper XML parsers that can also handle XSL style sheets. It doesn't make sense to me to develop non-XML approaches to templates. With an XML approach you can mix XML and other stuff from the database with XML templates (using Tcl 😉 to produce intermediate XML which either gets just shoved to the browser or rendered into HTML at the server for non-XML browsers. This seems to fit well into the architecture behind ACS of the web server being the database client.
3. re Tcl and not forking from ACS classic. I agree that not forking is far more important than language preferences. The contribution made by ACS is in having a working community system where the web server is the database client and the ongoing work on that is what makes the OpenACS contribution of adding support for Postgresql instead of Oracle worthwhile.
However my reference to killing several birds with one stone still applies. By disentangling the Tcl application code from the database dialect so you can support multiple databases (whether using XML or not) and ALSO disentangling the Tcl application code from the presentation so you can install upgrades without wiping out customizations (again whether using XML or not), you gain the side effect of also being able to add new ACS application functionality that can talk to both the presentation and the database and need not necessarily be written in Tcl (while retaining the existing massive investment in Tcl code plus the additional investment in disentangling that code, which will HAVE to be done at some point).
By using XML for both, OpenAccess could leverage the Tcl/XML work common to both these separate problems and hook into the momentum behind XML and the inevitable consequences of imminent changes in what browsers people are using. (XML not being central to the concerns of a database oriented web application could be almost as out of touch as database team not paying much attention to the web).
I guess whether that is practical or not depends very much on ACS classic. I have no knowledge and therefore no opinion on whether they could be persuaded to move in that direction. But it seems pretty inevitable that everyone will have to eventually. Not making XML central will soon be a bit like not making HTML central would have been when the web got going. ("What's wrong with telnet and ftp, they work don't they?")
