Forum OpenACS Development: Re: XOTcl remoting services

Collapse
Posted by Don Baccus on
This is very interesting stuff.

There are a couple of issues that will result in this code being a bit marginalized unless they're resolved.

1. I recognize the need for Stefan to be able to continue to view this code as a research project. However, OpenACS and .LRN are production systems and folks need to be able to depend on code stability. So at some point you're going to have to be able to say "here is our published API, it will remain stable at least in regard to backwards compatibility with previous releases".

2. Oracle support. Everyone knows that I've suggested we drop this twice now. Both times, the community has shouted me down. At the moment, at least, anything that's incorporated into OpenACS core or the mainstream .LRN stuff needs to support Oracle. I don't expect U Vienna to do this but at some point either a) the community becomes convinced to no longer support Oracle or b) Vienna partners with people using Oracle for .LRN/OpenACS in order to get a port working (and this is really impossible until the code stablizes).

I'm not trying to be negative with either of these points, just trying to state the reality within which we operate if we want our code to be adopted into the framework.

Collapse
Posted by Stefan Sobernig on
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.

Collapse
Posted by Gustaf Neumann on
concerning 1: what you are addressing is one of the reason, we were not publishing the code say, a year ago, when it started to do something useful. Code stability is reached best, when nobody develops the code further. note, that we are not taking about making it part of acs-core, or even xotcl-core. Once a package is fully documented, it reaches some natural state of code stability, since changes become more costly for the developer.

concerning 2: most parts of xotcl-core don't depend on the database at all, mostly the oo layer for the content-repository does. Stefan's code does not depend on this. Only the xotcl request broker uses the database to interface with the service contracts.

Technically, we could factor out the database dependencies for xotcl-core and make it different packages, which will complicate bootstrapping and increase the number of small packages. Alternatively, we could define a separate project (e.g. ooacs) which shares large parts of the code base with oacs, but which does not have the oracle constraints.