At any rate, aD's concept is a good step -- separating content from processing should be a design concept with easy-to-grasp consquences. Anyone who has had to work with "Product Designers" will know what I mean. (no offense to all the fine Product
Designers out there)
And this is important in more areas than simply upgrading. Take for
example "http://www.debian.org". Now, this is a set of static HTML pages generated from XML and then hand-tweaked. But this system allows us to provide translations to 7 or 8 languages from the same source template, and makes it a bit easier for non-catalan-speaking people to update the whole set of pages when changes are made. It would be nice to generate all of this on the fly -- and a templated display system would seem a good way to go about it.
The aD's concept seems more advanced that this, but would certainly be a big step in the right direction. As long as a site had not made changes to the functionality of a site, we could easily upgrade their system.
As for Jin Choi's arguments -- I certainly can't argue. I have no expertise in this area and would be foolish to second guess. However, I will point out that plenty of Perl programs are written using the DBI specification which allows them to map to a variety of
RDBMS's. I think this kind of abstraction is worth the potentially non-trivial performance hit. But that's just me. I've found that being completely shackled to a particular platform (even an RDBM) is generally not wise.
Under a system like the ACS, I imagine that a lot of time would shift to writing plumbing code that connects the ACS "generic code" to the particular database "driver". This "driver" is where the SQL would reside. This could just be another Tcl file that gets sourced by AOLserver.
What experiences have the rest of you had with database systems -- do you tend to have to move from one to another fairly often? Or are you able to dictate to your clients what they will use?