Hi,
Just a few answers/comments:
Install the PostgreSQL ODBC driver
This is basicly the idea of the interface: Document the PostgreSQL API once and use the documentation for both, direct ODBC (LAN) and WS (Internet) access. This is why I've called the package a "bridge" (-> OO bridge pattern).
run any query through SOAP
Hi Roc, that sounds very interesting. Could you provide us with the source code? It would be nice if we could offer both SOAP and XML-RPC. I'm not sure whether we'd integrate it "Phase 1", but we'd definitely adapt the design of the package in order to be extensible.
1. the service should use openacs authenticate and
permissions (via http/https) before executing a
call and/or screen based on ip and a hash, etc etc.
Hi Torben, that was our idea as well. There is a security token scheme from some bulk mail package from Malte Sussdorff that we'd use. So the user would authenticate once against OpenACS auth, obtain a hashed auth token and execute multiple calls with this token. The only issue with this is that the token has a unlimited livetime today. We might have to change that...
2. the call should be to a tcl API instead of db_* so
that values can be easily customized to meet
requirements that would complicate db_*, for
example to allow general audit features to work
(since ecommerce packages use them and this is wsrp).
Right, we're using the TCL API already for our prototype. Also, we need to extract fields from "extension tables" as defined in acs_attributes, so we had to discard early the use of the db_* interface.
But I don't understand the "audit" thing and how that relates to ecommerce. Could you elaborate, please?
3. there would be a table mapping "allowed" calls
to specific protocol access and openacs tcl api
(all other requests are refused and optionally logged).
Do you refer to introducing permissions, similar to the ones of the PostgreSQL database user? Maybe read and write permissions per object? That's an interesting idea. We've only been considering a all-or-nothing scheme until now.
4. there would be different urls within the package
for different protocols, for example: soap, xml, cgi,
and other third party standards (such as legacy ones).
Right, that was our idea.
prevent the splintering of services into innumerable
packages
I think I understand. So the extensibility towards SOAP would probably be the first step towards such a "unified" architecture, so we're back with Rocael and his SOAP interface.
Thanks a lot for the feedback so far, I really appreciate it.
Frank
mailto:frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/
