Don,
Thanks for the detailed response. Don't want to get into an argument
now as:
a) I'm basically just a lurker passing on info and not planning to
contribute to the urgent work going on at the moment.
b) More urgent at the moment to just keep it rolling as is, rather
than discuss things that aren't on critical path.
But here's some thoughts to keep in mind for later.
I agree that any efficiency improvements in query planning should
just be kept off critical path. Presumably db_exec_plsql achieves
that. But also presumably anything to do with query planning is
just as postgresql specific whether done one way or another.
Ensuring "portability" is different from actual "porting".
"Portability" just means not creating unnecessary
*obstacles* to later porting. Doesn't necessarily mean
doing much extra work up front to *further* reduce effort
of porting later by a more "generic" solution - that is
often illusory anyway.
Re portability generally, I suggest this be reviewed when the
current pressure is off and situation with ACS4 java and ACS5
more clear (and also concrete plans for other DBMS ports more clear).
The way I see it there's going to be a major problem keeping up
with aD's migration from Tcl to java.
That ACS roadmap from aD has a lot of food for thought:
http://www.arsdigita.com/wp/display/26811/26812.wimpy
My understanding is that the data model will shift in successive
ACS 4.x java releases as they move to both less RDBMS dependence
and *more* java dependence.
That may mean there should be less embedded Oracle java.
But it could also mean it's going to be a lot harder to
keep up with new modules from a Tcl platform that's been
abandoned by aD when they are doing more and more stuff
on the web application platform in java.
Up to now OpenACS has been focussed on PostgreSQL
(and AOLserver/Tcl).
It obviously makes sense to support Oracle as well for
the existing base of ACS classic users that are being
abandoned, and at the same time make it *easier* for
people who want to do ports for firebird/interbase, sap db
etc.
At present the work is still on doing a PostgreSQL
port in a way that avoids putting obstacles in the way
of other ports, unlike the previous situation where you
faced a severe obstacle now resolved by db-api.
Any other ports will still have to do a lot of work,
and if current port hasn't done work they will need to do to
cope with problems in the stored procedure languages
available to those RDBMSes, that just means they will
have to do that work for their RDBMS/web platform
when it's easier with PostgreSQL, not that current work
is creating obstacles or should avoid using postgresql
specific solutions to get what it's now doing done easier.
It should just avoid creating obstacles by specificying
appropriate interfaces.
eg You've got java crypto hash functions for Oracle and
can get them easily for PostgreSQL. Whoever needs them
for some other RDBMS will also need to solve the problem, so
any (layered) API adjustments necessary to avoid creating an
obstacle for them should be done, in case it turns out *they*
have to do it within the web platform instead of more easily
within the database as with Oracle and PostgreSQL. But a PostgreSQL
version including such necessary kernel procedures should
not be held up now just in order to save time for somebody
else doing something else later.
There's good reasons for having chosen PostgreSQL and
even when others are available they will still be good
reasons. One of them is that it can keep up with or
surpass Oracle.
Likewise AOLserver/Tcl is clearly the only relevant
platform for OpenACS right now. But others are likely
to become of interest once that's been done for OpenACS 4,
even if not done by same people working on current port.
Keeping logic in the database may enhance web application
platform portability more than it reduces RDBMS portability.
That's especially relevant with issues re AOLserver and likelihood
of people wanting to work with java based modules released by aD.
A lot of OpenACS users are likely to be disk bound due to not
having bucket loads of spindles like a large site, so the
performance of AOLserver may not be that relevant to them.
Proof that the ACS data model is what it's about, not the specific
code, has been demonstrated on the one hand by the porting to a
different dialect here, and on the other hand by shift to an entirely
different web platform at aD.
OpenACS could well be an umbrella for people
wanting more "Open" development of ACS with respect to web
platforms as well as SQL dialects. (Whether willingly or not
eg I noticed an item about someone being required to use PHP).
It isn't called OpenTclACS even though that's the current reality.
Doing application logic intended for java in Tcl could turn
out to be both more difficult and a bigger obstacle to acting
as an umbrella than doing some of it embedded in stored procedures
(as at present).
Anyway these are clearly issues for the core team and other
developers to resolve later, rather than for me to argue
about now, so I'm just passing on the thought.
Press on regardless 😉
