Forum OpenACS Development: Re: The future of OpenACS

Collapse
Posted by Malte Sussdorff on
The main issue is that most OpenACS applications depend upon page views.By that I mean that pages serve as a procedure. This makes it nearly impossible to reuse this code by a different protocol

I was wondering if this "problem" could not be solved by limiting the webservice to ad_form and listbuilder where pages that contain them can interact with them through the request processor. At least for ad_form this should be fairly easy to do, but maybe I am just having a good dream 😊.

Additionally i am wondering, if TCL does not maintain type information why don't we just expose this to the remoting functionality as a string. I understand all the benefits of having things typed and I think we could probably use your type checking from TWiST and make it generally applicable to ad_proc (just thinking out load, not looking into code), but my question would still be, is this such an issue for OpenACS.

I look forward to your client and if you need a dummy to test it against anything else but Google AdSense just make the code available, as we are (at the moment) looking into TSOAP and manual code generation for calling external WSDL compliant services.

Collapse
Posted by Tom Jackson on
With TWiST, you need a Tcl procedure to serve as the operation. An input message contains the arguments and the output message, obviously, the result. The only 'problem' is one of picking a procedure which exposes what you want. If the code which needs to execute is not packaged up this way, then the 'problem' is to write it, similar to what I would need to do for my qw.tcl file which processes all form submissions. Obviously my job is much simpler because I only have one page to deal with. On the other hand, I have the same issues for the applications which use query-writer: forms/pages which select, organize and display information. One advantage of query-writer is it contains a lot of data model information, so it could be used to auto-generate TWiST configuration files and create simple select (one or many) Tcl API and also use the qw_* API for insert/update/delete operations. (Since query-writer gets type information directly from the database, typing can be automated.)

Working with a procedure defined via ad_proc actually presents very similar issues as an application page. ad_proc serves many purposes, but the way it works makes it harder to expose as a web service. This is why TWiST works the way it does: configuration is done via <ws>proc, which provides a wrapper for the internal API. Inside this wrapper, you can specify any amount of code. Maybe you could source a tcl page and do something with the resultant state. Whatever goes on inside the wrapper, you just need to return a list which represents the output message.

One point about typing with TWiST: more important is the structural typing, such as the names and order of the complexType elements, how many of each of the elements, can it be missing, is there a default, if missing, does this indicate it is 'nil', etc. Otherwise, your return document will just be a smashed together mess, but internally TWiST does not care about types, just structure. Essentially the type information is a description of the template: what is the document going to look like. Nobody would ever suggest we just run a tcl script and return a list of all the variables, the results need to be formatted, and this is what the type specification does: defines the non-data parts of the document. The wrapper code doesn't need to know anything about XML or any of this configuration, it just needs to return a list which will be formatted into a document.

When the TWiST client is done it will only handle document/literal, whatever is available now is in the wsclient package of tWSDL. I think everything is in a web page, and it requires the ssl module to be installed, at least to use ns_https.