Hi,
Thank you for a modern SOAP client library. Prospects of talking to SOAP services from Python were very bleak before suds showed up on the horizon.
The library is very useful as it is but there is one implementation detail that if changed could make it even more useful. I'm talking about the reliance on urllib2 for sending the actual http requests. Since urllib2 throws away a connection after each request is finished it makes it much harder to implement NTLM authentication on top of it.
Why NTLM you ask? It is used by default on all those Sharepoint sites that seem to spread all over place. And unfortunately they will not go away anytime soon. Not at my work place at least.
I have even written my own SOAP client library so I can talk them. It is inspired by your API but it is based on lxml[1] for all the XML wrangling and httplib2[2] for all the request/response/authentication/cookies stuff.
It can handle a subset of WSDL and it works fairly well for the services I have to talk to. It will never will be as general as yours but it can handle NTLM authentication thanks to httplib2 and a plugin I wrote. Currently the plugin works only on windows because it depends on pywin32 being installed.
What do you think about switching the transport to httplib2? It is an extra dependency but it makes http handling easier. Or maybe one could come up with a simple interface and make the transport pluggable? With pluggable transport one could use pycurl[3] and have cross platform NTLM authentication solution.
Thoughts?
[1] - http://codespeak.net/lxml/ [2] - http://code.google.com/p/httplib2/ [3] - http://pycurl.sourceforge.net/
i've mentioned to jeff, how great his library is also. we were about to give up on python before i stumbled upon suds. and jeff has quickly followed up and resolved every issue we've had in a very timely manner. i now recommend suds to everyone i know :)
regarding use the use of httplib2.. even though this library is very nice and works well for you. it does have it's problems. i used it for one of my projects and it just couldn't handle the threading very well and was very slow. but when i switched to urllib2, threading issues went away and it ran very fast. most projects wouldn't have the stress requirements of this particular project, but still, i would caution making an switch to only use httplib2 for all situations.
bryan
On Tue, Nov 11, 2008 at 7:07 PM, Waldemar Osuch waldemar.osuch@gmail.com wrote:
Hi,
Thank you for a modern SOAP client library. Prospects of talking to SOAP services from Python were very bleak before suds showed up on the horizon.
The library is very useful as it is but there is one implementation detail that if changed could make it even more useful. I'm talking about the reliance on urllib2 for sending the actual http requests. Since urllib2 throws away a connection after each request is finished it makes it much harder to implement NTLM authentication on top of it.
Why NTLM you ask? It is used by default on all those Sharepoint sites that seem to spread all over place. And unfortunately they will not go away anytime soon. Not at my work place at least.
I have even written my own SOAP client library so I can talk them. It is inspired by your API but it is based on lxml[1] for all the XML wrangling and httplib2[2] for all the request/response/authentication/cookies stuff.
It can handle a subset of WSDL and it works fairly well for the services I have to talk to. It will never will be as general as yours but it can handle NTLM authentication thanks to httplib2 and a plugin I wrote. Currently the plugin works only on windows because it depends on pywin32 being installed.
What do you think about switching the transport to httplib2? It is an extra dependency but it makes http handling easier. Or maybe one could come up with a simple interface and make the transport pluggable? With pluggable transport one could use pycurl[3] and have cross platform NTLM authentication solution.
Thoughts?
[1] - http://codespeak.net/lxml/ [2] - http://code.google.com/p/httplib2/ [3] - http://pycurl.sourceforge.net/
fedora-suds-list mailing list fedora-suds-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-suds-list