We did something similar at Galileo, is a SOAP implementation to run any query through SOAP, and get the results in the client, an manipulate those as you usually do with the standard db_* API. I've been wondering if the community will be interested in something like this....

Usually the simplest option is the best one.

The ecommerce auditing feature basically tracks changes that users and admins make to editable data, see: http://openacs.org/doc/ecommerce/audit and a discussion on making this service available to any package or user action: http://openacs.org/forums/message-view?message%5fid=456993

You ask: Do you refer to introducing permissions, similar to the ones of the PostgreSQL database user? Maybe read and write permissions per object?

The mapping/filtering would be in addition to any permissions that are implemented at the url level and object level (including checking for read/write/create/delete permission on a called object before taking action on it).

Creating a general service has the potential of making the website vulnerable to complete tcl api access in a manner similar to how developer-support provides tcl api access to admins, or user input fields are vulnerabilities for certain attacks by blue meanies etc. If there will be any user-level or package-admin level configurable services (which saves having to hard code each one), then there needs to be a way to screen calls before they get processed in any way --similar to how html and html attributes are screened in user input now.

We've come up with the idea that OpenACS is really just a database [...]

The problem is that although the above is a useful metaphor and guideline, it is nowhere near 100% true of OpenACS in practice - nor should it be!

For example, look at how user creation is handled. Last time I checked, the Tcl user creation procs call a whole bunch of different helper procedures, in an entirely non-obvious fashion. There is an underlying simple-looking PL/SQL object-like API, but in fact it is not sufficent, it only does part of the work. Correctly creating a new OpenACS user is totally dependent on calling the correct Tcl proc. Now, that particular example could probably be alleviated by refactoring the existing OpenACS use creation code. But there must be many other examples. E.g., cacheing. Sooner or later, your XML-RPC SOA stuff is going to need some way to say, "Change X, and then please also flush the corresponding cache Y."

Non-trivial real-world integration with remote systems is going to require access to the OpenACS Tcl API in some fashion. Access to merely the PL/SQL (or plpgsql) API is not sufficient.

Moreever, it would probably be a bad idea to make the PL/SQL API sufficient! At least arguably, the gratuitous over-dependence on PL/SQL introduced in ACS 4.0 is one of OpenACS's core weaknesses - and OpenACS hackers much more expert than me seem to think so too.

Ideally, going forward I would like to see a complete, well-factored Tcl API running in AOLserver, which uses PL/SQL only where specifically useful, with no attempt to give the PL/SQL API full coverage. (I suspect Gustaf has some thoughts and has done some work along those lines, perhaps from a relatively XoTcl-centric angle.)

SOA-style programmtic control would then logically hook into this clean and comprehensive Tcl API. However, there's no reason you have to implement one before the other, you could build in some sort of general SOA Tcl interface now, use that to write whatever ad-hoc SOA functionality you really need right now, and then only later revisit a refactoring of the underlying OpenACS APIs. Indeed, getting SOA to work out in the wild, on real-world projects, would probably give you a lot of ideas about where and how you'd like to improve the OpenACS APIs in the future.

Also, above I repeatedly say "Tcl API" because that happens to be what OpenACS uses, but in this context Tcl is largely incidental - what I'm really talking about here is OpenACS's "application server API", and for better understanding, that's probably the term that should be used when talking to outsiders.

If OpenACS actually needed to support another in-process programming language, defining bindings for it to the canonical Tcl-based app server API would be pretty straightforward. But of course, such multi-language support is much harder and messier if you don't have a really good and clean canonical API - which is basically the current de facto situation in OpenACS.

Note, semi-related, the zipfile of the old code I posted back March 2005 to allow a client AOLserver to login under SSL to a remote OpenACS server is still available on my website.

First of all thanks for the great feedback. There are many consideratations that we'll include in the design.

Torben wrote:
> Creating a general service has the potential of making
> the website vulnerable to complete tcl api access in a
> manner similar to how developer-support provides tcl api
> access to admins, or user input fields are
> vulnerabilities for certain attacks by blue meanies etc.

I guess you're right. However, a simple, all-or-none version of the package would be reasonable first step in a project with several phases, wouldn't it? We'd have to make sure thought that we can reasonably introduce suitable permissions later. The first step for us is to connect with some trusted 3rd party applications, which would get full access.

One simple way could be SELECT/UPDATE/INSERT operations per _object_type_ (not per table). With DynField we've got a mapping anyway from object_type to tables, so there would be no issues with using object types in the API. Then you could add permissions per user group and object type. That's quite easy, performant and consistent. What do you think?

> I imagine implementing a hash that works similar to how
> the session cookies

Right, that's the way.


Andrew wrote:

> > We've come up with the idea that OpenACS is really
> > just a database [...]
>
> The problem is that although the above is a useful
> metaphor and guideline, it is nowhere near 100% true
> of OpenACS in practice - nor should it be!

Hi Andrew, I see you point. However, we're probably still going to go that way. That's because it's "low hanging fruit". It will probably take us some 2-3 days to implement the entire f... API for about 80 different object types. It would take us weeks and months to do it on the TCL API level. Also, we've based ]project-open[ pretty much on the database, and all of our main objects are perfectly accessible on the DB level.

So I guess we will have to stick with the SQL and PlPg/SQL access if we want to get a moderately complete API. Also, there would be an incredible _testing_ complexity with a TCL API, because TCL and the API are dynamically typed, and any integrator would get zillions of little issues (or do you have an idea for efficient testing with a high coverage?).

However, we could design the API so that we could deal with exceptions such as your "user" case. We could catch these exceptions (asuming that there is a finite number of them!) and "redirect" them to a TCL function. What do yo think?

> could build in some sort of general SOA Tcl interface
> now, use that to write whatever ad-hoc SOA functionality
> you really need right now

That's not an options for use, because it's our customers who demand a complete interface, so that they can write their own integrations with their own team.

Maybe I'm a bit simplistic, but I had to learn the hard way that 80% solutions win (and what part of OpenACS is not an 80% solution?), because they're the only ones that get implemented in a limited amount of time. I really like the "Make simple things easy to do, and make hard things possible" approach. Atleast this API is going to be working and to be quite complete...

Bests,
Frank

frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/