Prev: A "scopeguard" for Python
Next: Eric4 vs Python3.1
From: BlueBird on 23 Mar 2010 08:38 On 5 mar, 13:19, lbolla <lbo...(a)gmail.com> wrote: > On Mar 5, 10:01 am, BlueBird <p...(a)freehackers.org> wrote: > > > > > > > On 3 mar, 20:35, Stefan Behnel <stefan...(a)behnel.de> wrote: > > > > BlueBird, 03.03.2010 17:32: > > > > > I am looking for aSOAP1.2 python client. To my surprise, it seems > > > > that this does not exist. Does anybody know about this ? > > > >SOAPmay be an overly bloated protocol, but it's certainly not black magic. > > > It's not hard to do manually if you really need to: > > > >http://effbot.org/zone/element-soap.htm > > > But this requires a goog knowloedge ofSOAP, in order to parse > > everything correctly. The reason I want to use a ready-made client is > > that I have about zero knowledge aboutSOAP, and even more in the > > differences betweenSOAP1.1 and 1.2 . > > > cheers, > > > Philippe > > I use a thin custom-made python wrapper around gSoap[1], which is tens > of times faster than ZSI. I looked at gSoap and the solution seemed really nice. They can generate C that I can call with ctypes. The only problem is that I am working on a closed source software and their licensing cost for close source were too expensive for my company. After much much digging, we found out the problem and managed to solve it with SUDS. When calling a .NET service, you should not reference the soap envelope spec with 'http://schemas.xmlsoap.org/soap/ envelope/' but with 'http://schemas.xmlsoap.org/soap/envelope' . The .NET server implementation seems to be very picky about the last / . Yeah for SUDS and oooooh for .NET cheers, Philippe |