Forum OpenACS Development: Re: Tcl Web Services Toolkit: TWiST

Collapse
Posted by Malte Sussdorff on
Tom, provide a page to which OpenACS can give a procedure name of your toolkit and it redirects us to the appropriate procedure documentation, then this can be easily implemented in the OpenACS api-doc if there exists an OpenACS package for your work. It would show up on the right hand sight of the API Doc below the search for TCL and AOLserver procedures.

In an ideal world I would be able to register all procedures with their names within the API Browser, so that searches for "string" would turn up the commands for the TCL string function, but this is not how the API Browser works *yet*.

Writing a package for OpenACS only makes sense once the API has stabilized though, which holds true for any wrapper functionalities.

I have to correct myself, if someone is interested in a tighter integration between tWSDL / TWiST and OpenACS then  write procedures similar to the <ws>* procs in OpenACS "style" which make use of functionalities that only make sense if you have installed OpenACS. We have ample of examples where OpenACS wraps existing external API into it's own functionality blocs, like ad_return* or ad_proc .... So do not write a simple wrapper which does not add any new functionality except documentation,  but I guess from my posting it was not obvious that this advantage comes in hand as well 😊.

Collapse
Posted by Tom Jackson on
My suggestion has been that a 'value added' OpenACS package should start with tWSDL. With the interactive features of a web application, you could provide even more assistance to the developer than what is provided with TWiST. For instance, you could guide the developer through the process of proc selection, type development, testing, documentation, etc. These are the logical processes required to create and document the web service, but the developer doesn't necessarily need to know the details of the API, if they have a wizard type package. BTW, both tWSDL and TWiST are already wizard like since the main function calls simply fill a database and write code, setting up the server, TWiST handles the boring details needed to please tWSDL.

However, if I were to write a quick 'integration' package for OpenACS, it would import the correct version (for the OpenACS package) from the google code repository. After that import, it can then be packaged up into an .apm file for distribution, or maybe the package would simply do the import upon installation. The package would then provide the TWiST API. The next step would be a wizard type interface which would produce a TWiST configuration file.