Andrew, the reason for the tsoap package was simple:
- There was no SOAP package for OpenACS available, that works with a pure SOAP gateway (not XML-RPC).
- We needed an implementation of the SOAP package to work with tDOM instead of TclDOM, due to the fact that OpenACS relies on tDOM.
- The goal is to create SOAP request in your own procedures (look at babblefish.tcl) and parse the result automatically.
- It should be easy to work around character set conversion problems as well as BASE64 decoding, that occured with the out of the box parsing.
So, the reason is stated above and the goal is to have a general SOAP parser and request generator for integration of other webservices using OpenACS as a client. Obviously, if we define a standard API on how to access our objects (similar to the /o approach in 5.2), it would be very easy to provide our objects to the outside world. For more complex web services we'd have to see where the demand goes. It should be a piece of cake to offer the add/edit/display/delete interface of the CR using SOAP calls and maybe even XML-RPC. Once we stumble upon a project that requires more thorough SOAP integration in this way, we will definitely include this in one way or another with OpenACS.
