Forum OpenACS Development: Response to ACS Roadmap from aD - worth a look for OpenACSers
ACS Roadmap. Still catching up with bboard postings. Could
anyone point me to specific messages/threads that would
get me clear faster on OpenACS Roadmap?
Re Don's comment on having "forked" already and:
""folks in the know" are going to be more interested in OpenACS 4.x than aD 4.x - multi-db support's a popular idea."
and related comments under "current short term happenings".
My impression was that the Tcl could just as well be described
as "picked up and continued" rather than "forked" in the light
of the ACS Roadmap confirming further development is effectively
discontinued at aD. Either way it will obviously diverge since one will continue developing and the other won't, so that's just a matter of terminology.
But I also thought the initial OpenACS 4 Oracle DDL would be largely identical to the ACS 4 Tcl Oracle DDL and ACS 4 java Oracle DDL, so no "fork" there yet. Have I got that wrong?
If that's true about Oracle DDL then current short term situation looks to me like OpenACS 4 PostgreSQL DDL is still a "port" of the SQL rather than a "fork" of the SQL. Same for DQL and DML seems implied by concept of Query Dispatcher. That isn't just a difference in terminology.
The SQL and Tcl or java are after all running in separate processes connected only via protocol adaptor interfaces, so at least in *theory*, one *could* fork without the other doing so if they still maintained a common abstract data model that had implementations for different RDBMS SQL dialects on one side of the interface and different web application platforms on the other side (plus relatively minor interface adaptations on each side for the purpose of maintaining that common abstract data model given the specifics of each implementation).
It may turn out that will prove impracticable or undesirable. But as far as I can see it is the *current* situation for Oracle SQL that can be used with either Tcl or java and could possibly become the situation with PostgreSQL SQL that could be used with either Tcl or java (or python 😉 *if* a deliberate choice was made to maintain a common data model, whereas it will diverge if a deliberate choice is made to fork the data model rather than port it in both directions.
I would have thought that if aD is interested in possible future
database independence from Oracle, it would be likely to roll the Query Dispatcher concept and the PostgreSQL port of SQL back into ACS5 or earlier when doing the more abstract database API for java. The macro processor might help with that, just as it helps with migration from ACS 4 Tcl to ACS 4 java.
Even if aD is more interested in MS Sqlserver than PostgreSQL in the short term, a general approach that can extend to PostgreSQL once they do go for database independence, would seem just as logical for ACS as for OpenACS. After all PostgreSQL was far less suitable for commercial contracts before than it is becoming now.
So if aD *is* aiming for (eventual) DBMS independence with a more abstract database API for java, I don't see why people wanting
multi-db support would necessarily find OpenACS 4.x more interesting than ACS 4.x. Developers wanting AOLserver or OpenNSD Tcl support would, but why should users be more interested in that, than in the range of modules and features available from each?
The Roadmap for ACS says:
"Oracle (with SQL abstraction support *shortly*)" (emphasis added) in a column that is headed "ACS 4.x, 5 Java". It doesn't seem to imply that this won't happen until ACS 5.
Is there some thread I should read confirming that, (and explaining why), a definate decision to fork the SQL (as opposed to Tcl) has already been taken?
