Forum OpenACS Q&A: Response to InterBase port interest

Had aD been more accomodating of this, IMHO, I don't think
the OpenACS people would have split off.

Absolutely right, and we haven't really split off in that we've only forked the code in the sense of making the minimal changes necessary to support PostgreSQL. We considered a deeper fork to implement modularization, etc but aD has stepped up to the plate with the package manager and other needed redesign and implementation of the core technology.

So, not forking is a goal of the OpenACS project.

I'm extremely supportive of aD's wanting to support IB if doing so pushes aD into implementing data abstraction to the extent that a single source tree can support multiple databases.

Doing so would almost bring OpenACS to an end in the sense that the maintenance and porting job would be much, much simpler than it is today. Who can argue against this?

Of course, it is a pity that suggestions that aD work to make it much simpler to support a second RDBMS engine were explicitly rejected in the past. I realize that aD's openess to the notion of supporting IB as well as Oracle is due to new folks who are on board who perhaps aren't quite so entranced with the notion that Oracle is the only RDBMS worth using. In other words, it is a matter of timing. New people have come aboard with new notions of what aD should do with the ACS, and that's a good thing.

What would really be great would be if aD would make a commitment to supporting not only IB, but PG. The thousand folks who've downloaded OpenACS are certainly an indication that there are a lot of people interested in ACS/pg. I don't see any particular reason to believe that IB is significantly superior to PG, if it is superior at all. Certainly in the feature department IB and PG are comparable, with IB ahead in some areas (most notably outer joins and a storage manager that reclaims space without the need to "vacuum"), PG in others (greater Oracle compatibility). In terms of performance they're probably both comparable under real load, and they share virtually identical row-level locking algorithms, making each much better in high-concurrency situations than (say) MS-SQL.

So when we've kicked around the idea of supporting IB as part of the OpenACS project, it hasn't been in the context of dropping PG support. It has been in the context of building in data abstraction so that we could support BOTH RDBMS systems from a single source tree.

There are four reasons we've not tried to put together a project thus far:

1. IB hadn't yet released their "super server" in Open Source.

2. Doing database abstraction to the level we'd discussed would commit us to a fork from ACS Classic sources, something we've been loath to do until 4.0 (it would require a fork because historically aD's been cold to the idea of modifying ACS Classic in such a way, as I mentioned above).

3. Limited resources - we're doing this without compensation which means we do it in our spare time.

4. PG has worked a lot better than some folks thought it might, which has probably lowered the enthusiasm for doing the work a bit.

Now, if aD is to support IB, it would be idiocy to do so with a second source tree rather than rework the core technology in order to abstract out queries. If this work's going to get done, it is certainly doable in such a way as to make supporting PG out of the same tree very practical.

If it is impractical to support a single source tree for Oracle & IB due to aD's business needs, then Sebastian should really be working within the OpenACS project so we can at least support PG and IB from a single source tree. This implies a fork, yes, but only into two rather than three trees. Sub-optimal, but not worst case.