Incidentally, while supporting more databases
(e.g,
MS SQL Server)
for OpenACS is very cool from a gee-whiz technical achievement point
of view, in practice, it's hard for me to imagine why anyone would do
it for any practical technical (as opposed to marketing) reason.
OpenACS has Oracle, the market and capability leading closed-source
database. OpenACS has PostgreSQL, the market and capability leading
open-source database. OpenACS already has the two best databases from
both worlds, why would anyone want to invest a huge effort to instead
use an inferior database?
The only entirely rational technical reason I can imagine is someone
with a large committment to a legacy app using a different RDBMS
(Sybase or MS SQL Sever, say), and their new OpenACS installation
must, for some hypothetical reason, directly run
OpenACS in the same database as their legacy app. Which sounds pretty
far fetched to me... Particularly since most organizations
integrating OpenACS into a large legacy app would probably
insist on using an entirely serparate database installation
for OpenACS, be it Oracle, Postgres, Sybase, or whatever.
Or perhaps there's the, "Our vast huge company uses only database X,
we don't want to have to even think about ever supporting any other
database" argument. But supporting a port of OpenACS sounds like much
more work than simply learning to use Postgres, or even Oracle for
that matter. So is that a valid or a specious argument?
John, you know more about this than me. As long as we're already
off-topic, I'm curious, does some big organization porting OpenACS to
a new database really make sense from a hard-headed IT
management point of view? Or is it solely a potentially critical tool
to get in the door and pitch the OpenACS solution to, ah, less than
entirely hard-headed IT managers and staff? Or somewhere in between?
