Forum OpenACS Development: Response to Current short-term happenings...

Well, to some degree I'm going to have to disagree with your comment regarding putting in extra up-front work to make porting easier. Our job would've been far easier if aD had taken portability as a goal.

This is, for instance, the major reason why they're pulling application logic out of the RDBMS and into Java. In most cases the effort involved isn't much different for the initial implementation, but it makes a huge difference in the level of difficulty involved in porting to a new RDBMS.

I have a fair amount of experience with portability issues, as my old software company (now defunct but in business for 13 years) was based on optimizing compiler technology designed and mostly written by me, supporting four languages and about a half-dozen minicomputer and microprocessor families.

I should clear up one misunderstanding - the OpenACS project, at the moment, isn't structured to keep up with the aD migration from Tcl to Java. For one thing, aD isn't really planning a migration path and recommends that those who want to dive into their Java future do so ASAP. It's more of a break than a migration, in other words, at least for the code (as opposed to all those migratory users!)

What we call OpenACS 4.x, then, is now and forever will be Tcl based. I say this with assurance because aD isn't going to cut right to ACS 5.x. In other words, there will soon be no confusion between ACS 4.x vs. ACS 5.x once aD follows through on the published plan. ACS 4.x == Tcl == the past. ACS 5.x == Java == a bright shiny future.

If the Tcl version, i.e. OpenACS 4.x, continues to evolve it will be due to the efforts of the community here, not aD.

Now - will this community drift off and adopt Java wholesale, or will enough folks be satisfied with OpenACS (Tcl) 4.x to grow it and continue to add to its functionality? I don't know the answer, frankly. My guess is "Yes, this community will continue to grow OpenACS 4.x and not just run to ACS 5.x". But I could be wrong.

It's not something I'm thinking a lot about, frankly. ACS 5.x isn't going to be available for some time. aD is interested in multi-db support but has no resources available to work on actually supporting anything other than Oracle with ACS 5.x for the rest of the year (as announced in the conference call). We can't port it ourselves because it doesn't exist.

So ... not being able to solve problems that are totally out of my control, I'm perfectly willing for the moment to ignore their very existence. We'll see what happens with ACS 5.x and we'll see what happens with aD and their efforts to bolster their image in their user community and we'll see what happens with the folks here.

Actually, when you say things like this:

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.

I get the impression we're thinking much alike. The specifics regarding the use of Oracle SMTP utilities fall into an area where there's already perfectly reasonable support within OpenNSD, so dragging that stuff out of the db and into the Tcl application layer is no big deal and solves the problem for any db (by removal).

I'm sure there will be instances where we won't seek an immediate all-encompassing solution, though. In particular, the very existance of PL/SQL and PL/pgSQL code is essentially dodging the bullet. If the OpenACS 4.x community thrives and doesn't drift off to Java-land, and if there are those in the community who want to support (say) InterBase, well...there will be a lot of work to do due to all that programmatic code buried in Oracle/PG.

At that point, it might make sense to start pulling logic out of the database and ending the dependence on PL/SQL+PL/pgSQL but that is a bridge that will be crossed later. If ever.

From reading your post I get the impression you think that it might be possible to use Java modules with the ACS Tcl 4.x core. If I read you correctly, I'll have to point out that as far as I know aD has absolutely no intention of supporting hybrid sites. I don't think that scenario is a viable one, frankly. You might be able to migrate to Java by rewriting your entire site (i.e. your customizations to ACS 4.x) and the similarities in datamodels may make it possible to migrate your accumulated data, but to do so will mean switching from ACS Tcl to ACS Java entirely.

I think the bottom line is that the Java future will represent a clean break for those who take that path. No code blending. Datamodel similarities will lower the bar for those who want to switch, that's about it. I don't think any decision we make regarding how much logic to leave in the db vs. the Tcl application layer will be relevant in practice.