This is an extremely important question. We completely expect people
to be able to move from ACS Classic 4.2 to OpenACS 4.x. OpenACS 4.x
will be Oracle compatible for that very reason. While this will not
initially be a one-step migration, we expect that plenty of interested
contributors like yourself will help us build the tools to make it easier!
The OpenACS 4.x design so far has not affected the core APIs. The big
changes are in the APM and in the Content Repository, although those
should add flexibility with little incompatibility. Your best bet in
building your application is to make sure that you:
- build standard packages using the APM.
- use the DB API at all times. Do *not* use the CMS's custom DB API.
Use the standard DB API and make sure to name your queries correctly
(unique names per Tcl file for single-page Tcl files, unique names per
Tcl proc otherwise).
- use as much SQL92 standard as possible in Oracle. We're going to
remain Oracle compatible, but who knows, you may be so pleased with
OpenACS you'll want to switch to PostgreSQL.
- don't use Java in Oracle. If you absolutely must use Java, use ns_java.
And if you want to help, you should get the latest OpenACS 4.x as we
develop it, and see how soon you can start writing your code for it.
Depending on your specific design, you'll be able to jump on board
somewhere between end of June and beginning of August.
As ArsDigita builds ACS Java, we want to offer the community the
choice of continuing down the current path with maximal architecture
and code compatibility. You'll have the choice to migrate to
ArsDigita's new ACS, or to stay the Tcl/AOLserver route with OpenACS
4.x. Choice is a very good thing.
