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/