David Watson has a response to Paul Prescod's email.
Some random thoughts as a SOAPBuilder.
If you require the HTTP GET arguments to be in a particular order (a rather unnatural restriction), OR you have an infrastructure which supports named parameter association, then the server implementation would be rather straightforward. You get a request, its intent is rather obvious and the data is easy to parse, so you simply inject the results into the appropriate portion of the implementation downstream from where the XML parsing would have been done.
The client side is another matter entirely. The encoding is certainly not difficult. Deciding when HTTP GET is appropriate is the issue. If all of the parameters are simple types, and there are no SOAP headers involved, and the overall length is not more than a couple of hundred bytes, then GET might be still be appropriate. Slightly more processing, requires two code paths, but overall still doable. The real twist comes in when the suggestion is made that GET usage must not be used for unsafe operations such as write, update, modify, tell, buy, agree. This requires the toolkit to infer the intent of the caller. This increases coupling and complexity. And some of this knowledge MUST come from outside of the toolkit, making usage of the toolkit more difficult.
10:59:38 AM 
|
|
