Again, if we worked out a common tool for creating objects, with us maintaining an Oracle back-end and you
guys maintaining a PG back-end, we'd both save a lot of time.
We spoke a bit about the direction you're thinking of taking when I was at aD in early January. Done well, abstraction of this sort would be a great help. Not so much in porting but in maintenance, i.e. once ported these objects would often survive changes in client code without needing to be changed themselves.
And when change at this level's required, it will be isolated to a set of objects rather than scattered willy-nilly through a couple hundred thousand lines of source code.
ACS4 abstracts things to some extent through the use of a lot of PL/SQL, which then has to be ported to programmatic languages supported by other databases if it is to run somewhere else than on top of Oracle. PG has PL/pgSQL, but not all RDBMS's have an equivalent (and I think IB falls into that category).
So, yes, the approach you're talking about has the potential to be a big help. After OpenACS 4.1 is underway I'd love to take a look into providing PG support for the stuff you're working on. Again, I'll be in Boston for much of March ...
For folks reading this scratching their heads about the implications, we're not talking about ACS 4.1, which is a fait accompli, but rather the future.
