On 19 Feb, 16:59, Paul Watson <[EMAIL PROTECTED]> wrote: > > Have I offended? My apologies if I have. I thought I showed that I had > done some homework and used Google and did the other things to show that > I was willing to put forth some effort. Please tell me if I have missed > something. If I should look somewhere besides Python for doing SOAP, > then please say that also. Thanks.
There's a Wiki page here about Web services in Python: http://wiki.python.org/moin/WebServices I don't think that there's been a great deal of visible activity around SOAP in the Python community other than that you've already noticed. I entertained the idea of doing some more complete SOAP support as an add-on to the libxml2dom project, but not wanting to implement all the related specifications (schemas, service descriptions), I struggle to see the benefit compared to simpler solutions. That's not to say that SOAP has no value. Clearly, if you consider the different "use cases", SOAP is probably more appropriate for some than other solutions would be. If one were exposing some kind of repository through some kind of Web service, I'd consider approaches like REST, along with technologies like WebDAV (which overlaps with REST), XML- RPC and SOAP. But if the Web service were to involve issuing relatively complicated queries, and/or the repository wasn't strictly hierarchical (or couldn't be elegantly represented in such a way), then it would arguably be less appropriate to deploy a "pure" REST solution, favouring XML-RPC and SOAP instead. What undermines SOAP for me is that if I'm not too interested in treating it like some kind of RPC mechanism, then I can get most of the pertinent benefits from exchanging plain XML documents. You can, of course, do SOAP like this, but the obligation to look after the boilerplate elements (which should permit lots of fancy features like "routing", if such stuff is actually used in the real world) seems like a distraction to me. Paul -- http://mail.python.org/mailman/listinfo/python-list
