Don, thx for these two comments.
Btw, I don't consider your attitude negative at all, _honi soit qui mal y pense_.
First, I want to make sure that there is no misunderstanding: We certainly do call for a more generic and viable solution in terms of call abstraction & remoting for OpenACS. However, this is not necessarily to be found in our work alone! All I want to stress at this point (before we can play our card = upcoming prerelease) is that any decision (either by the single developer or the OCT) should not be limited to a rough "SOAP-goes-Core".
ad-1 :: published API & code stability
As for the API, this is -- as prominently mentioned by Gustaf Neumann -- our top priority for the prerelease. As long as you refer by "code stability" to a stable interface, we certainly have to meet this fundamental requirement. However, the interface is already matured (though still not stable) through incorporating the experiences from the projects mentioned above and beyond. Moreover, the interface will certainly be familiar to many of you as we tried to stick with established notational forms, for instance, when declaring a contract the OOish interface resembles the good old arraylist.
ad-2 :: oracle support
I cannot comment on the fundamental issue here, nor the overall opinion in the community. Currently, the entire request broker operates on the established collection of db calls offered by acs-service-contract with only minor extensions. However, there is currently not a fundamental rewrite at this level (which might though be a good thing to do at some point) and therefore the Oracle issue should not be a barrier in this respect.
