From burak.arslan at arskom.com.tr  Tue May  6 01:30:38 2014
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Tue, 06 May 2014 02:30:38 +0300
Subject: [Soap-Python] New Spyne Mailing List
Message-ID: <53681F1E.2080202@arskom.com.tr>

Hi All,

FYI, I just set up a new mailing list for spyne: people at spyne.io

You can use either people-subscribe at spyne.io or the mailman web 
interface (http://lists.spyne.io/listinfo/people) to subscribe.

It's a brand new mailman installation, so please let me know about any 
issues you might run into.

By the way, Spyne master branch will receive mostly bug fixes in the 
coming weeks. I hope to put something on pypi in around a month. It's 
going to be a huge (diffstat says 228 files changed, 20431 
insertions(+), 7077 deletions(-) where the whole repo is ~50kloc) yet 
fully backwards-compatible release (except bug fixes) so I may decide to 
go through a couple beta releases before making a stable 2.11 release.

I'll give more details closer to the release date.

Best,
Burak


From reingart at gmail.com  Fri May  9 16:28:36 2014
From: reingart at gmail.com (Mariano Reingart)
Date: Fri, 9 May 2014 11:28:36 -0300
Subject: [Soap-Python] backlog of old postings
In-Reply-To: <CAA_9swrVJBuk-rpx5czG=z8c2x1k_vQcJ4enSLxLS0cNt4a8AQ@mail.gmail.com>
References: <CAA_9swrVJBuk-rpx5czG=z8c2x1k_vQcJ4enSLxLS0cNt4a8AQ@mail.gmail.com>
Message-ID: <CAPyeU7Sp_dr1OZ_+JW9Ch9W4m3Osqgx9eC3tLNinCMVQHDbBKw@mail.gmail.com>

Hello Python SOAP list,

I'll be volunteering with the administration/moderation of this list.

Sorry for the delay and inconveniences, I'll try to help with pending posts
ASAP.

Please fell free to contact me if you have any issue with this list.

Best regards,

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com


On Sat, Feb 8, 2014 at 2:10 PM, Sheila Allen <bradallen137 at gmail.com> wrote:

> Hi Python SOAP list,
>
> Sorry I lapsed on my list moderation chores...there were a couple of posts
> from the past few months which were legitimate non-spam messages to the
> list, which had gotten stuck and needed to be approved.
>
> I'm not much involved in in this list anymore, so if anyone else wants to
> take over list moderation, let me know. Otherwise I'll keep checking it
> once in awhile.
>
> --Sheila (formerly Brad) Allen
>
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> https://mail.python.org/mailman/listinfo/soap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20140509/adc1d68c/attachment.html>

From felix.schwarz at oss.schwarz.eu  Fri May  9 16:45:52 2014
From: felix.schwarz at oss.schwarz.eu (Felix Schwarz)
Date: Fri, 09 May 2014 16:45:52 +0200
Subject: [Soap-Python] Guidance on approach
In-Reply-To: <2db6854e16014fcc8a03bf75fb274edc@exch.activenetwerx.com>
References: <2db6854e16014fcc8a03bf75fb274edc@exch.activenetwerx.com>
Message-ID: <536CEA20.7050606@oss.schwarz.eu>


Am 14.04.2014 18:53, schrieb Joseph L. Casale:
> I have started looking at spyne and the examples but none of these emulate anything
> similar to such an approach.
> 
> Anyone know of any similar code they could reference me to so I may get a better
> understanding of how to accomplish this with spyne?

My experience with spyne was that a lot of stuff I needed was just not
possible. Dealing with invalid responses was one of the points there (the
other issue I still remember was custom handling exception/logging).

To be fair the spyne developer was pretty responsive but in the end I decided
to go with soapbox because it's architecture was really centered around
SOAP+XML so I could do everything I needed.

See my response to Deepika Nagpal regarding a more in-depth advertisment of my
Soapbox fork: https://github.com/FelixSchwarz/soapbox-bsd

Felix



From felix.schwarz at oss.schwarz.eu  Fri May  9 16:30:57 2014
From: felix.schwarz at oss.schwarz.eu (Felix Schwarz)
Date: Fri, 09 May 2014 16:30:57 +0200
Subject: [Soap-Python] soap library for python-3.x
In-Reply-To: <20140425095615.M32856@cdot.in>
References: <20140425095615.M32856@cdot.in>
Message-ID: <536CE6A1.6000209@oss.schwarz.eu>


Am 25.04.2014 11:56, schrieb Deepika Nagpal:
> We have to start a project for developing a soap server in python-3.x for which I am
> looking for a soap server side library. Please let me know what are the options
> available for python-3.x and which of these libraries are actively maintained. Thanks.

(Disclaimer: I'm one of the maintainers of "soapbox-bsd".)

I think you should check out soapbox-bsd which is the only real option for
server-side SOAP in Python: https://github.com/FelixSchwarz/soapbox-bsd

I realize I made a bold strong statement so let me quickly explain why I'm
saying this.

A bit of background first:
- I'm not doing SOAP for fun or to provide "just another RPC layer".
- I need to implement SOAP protocols defined by others without any chance to
  change a tiny bit.
- I have an unknown number of SOAP clients, most proprietary desktop
  applications from a random number of ISVs (each with their own bugs). I
  need to be interoperable with every single one.

>From my experience rules out any library which supports SOAP among others. I
needed complete control over the complete request/response parsing (including
the ability to process/return invalid SOAP to satisfy specific clients).


SoapBox was built by Damian Pow?zka, later on taken over by guys at Flight
Data Services. However these guys changed the license from BSD to OSL in early
2012 (and essentially stopped maintenance shortly after). In late 2013 I
forked the last BSD commit and contributed many fixes (including non-Django
support).

Since early 2014 a small team of developers from Polyconseil (french
consulting company) contributes most of the changes. I have a pretty big merge
queue for my repo but I hope to clear that in the next few days.

Pros:
- maintained by professional software developers (no hobby project), multiple
  companies involved.
- active community management: I checked several of the original soapboax
  forks, reached out to the authors and was able to get relicensing
  permission from them, pushing their "private" changes into soapbox-bsd.
- we support Python 2.6-3.x (travis build server)
- abstraction layer for XSD data types with the goal that the abstraction can
  support all allowed XML schema features
- supporting different versions of SOAP/WSDL
- supporting multiple web frameworks: Pyramid, Django, WSGI, ...
- basic code generation from WSDL (you'll get a basic model skeletton pretty
  quick for simple WSDLs, probably syntax errors/missing features for complex
  WSDLs)

Cons:
- little documentation outside the source
- not polished to use as "black box" library
- not installable through pypi
- quite a bit of API changes at the moment
- you should expect to see missing features where you need to implement
  datatypes yourself or implement missing SOAP functionality.

In the future we'll likely rename the project to make it completely
independent from Soapbox and then we'll fix also the "pypi installation" and
surrounding issues.

I tried several other libraries (e.g. spyne, pysimplesoap) but none of them
gave me complete control over request parsing/response generation.

Felix

From jcasale at activenetwerx.com  Sat May 10 01:33:06 2014
From: jcasale at activenetwerx.com (Joseph L. Casale)
Date: Fri, 9 May 2014 23:33:06 +0000
Subject: [Soap-Python] Guidance on approach
In-Reply-To: <536CEA20.7050606@oss.schwarz.eu>
References: <2db6854e16014fcc8a03bf75fb274edc@exch.activenetwerx.com>
 <536CEA20.7050606@oss.schwarz.eu>
Message-ID: <63dbac73f75047b3bc5c2d5f16a6172a@exch.activenetwerx.com>

Hi Felix,

> My experience with spyne was that a lot of stuff I needed was just not
> possible. Dealing with invalid responses was one of the points there (the
> other issue I still remember was custom handling exception/logging).

With the spyne developers help, I managed to get my project sorted out.
The library managed to accomplish all that I required, with Buraks incredible 
effort it is working out very well.

Thanks for following up.
jlc

From reingart at gmail.com  Sat May 10 20:20:39 2014
From: reingart at gmail.com (Mariano Reingart)
Date: Sat, 10 May 2014 15:20:39 -0300
Subject: [Soap-Python] soap library for python-3.x
In-Reply-To: <536CE6A1.6000209@oss.schwarz.eu>
References: <20140425095615.M32856@cdot.in> <536CE6A1.6000209@oss.schwarz.eu>
Message-ID: <CAPyeU7QfjFYQ8u928=J6TOt3zFGnSfF=KWLdAkd3j4b5+9PZNg@mail.gmail.com>

On Fri, May 9, 2014 at 11:30 AM, Felix Schwarz <felix.schwarz at oss.schwarz.eu
> wrote:

>
> Am 25.04.2014 11:56, schrieb Deepika Nagpal:
> > We have to start a project for developing a soap server in python-3.x
> for which I am
> > looking for a soap server side library. Please let me know what are the
> options
> > available for python-3.x and which of these libraries are actively
> maintained. Thanks.
>
> (Disclaimer: I'm one of the maintainers of "soapbox-bsd".)
>
>
(Disclaimer: I'm the creator and one of the maintainers of "pysimplesoap".)

TL;DR: see the summary at the end

I think you should check out soapbox-bsd which is the only real option for
> server-side SOAP in Python: https://github.com/FelixSchwarz/soapbox-bsd
>
> I realize I made a bold strong statement so let me quickly explain why I'm
> saying this.
>
>
Personally, I don't believe in "one size fits all", that could tend to a
harmful monoculture thinking that could not take into account different
user needs, expertise, backgrounds and use cases. Diversity is good. IMHO


> A bit of background first:
> - I'm not doing SOAP for fun or to provide "just another RPC layer".
>

Me too, PySimpleSOAP is focused on SOAP and was born from a commercial
project to build interfaces for Argentina's Federal Tax Administration
 (AFIP, equivalent to IRS in the US), originally for electronic invoicing,
but then it spawn to agriculture, foreign trade, customs, foreign exchange,
etc.
Also, it added support for even other government agencies like medical drug
traceabilitty, precursors chemical, etc.:

https://code.google.com/p/pyafipws/

It is currently one of the most used interfaces to consume the AFIP
webservices and has a forum with +230 members

http://groups.google.com/group/pyafipws

I also offer commercial support for the SOAP library itself:

https://code.google.com/p/pysimplesoap/

I'd been contracted by several internatinal corporations (including Tier2/3
ERP vendors), hundreds of SME and profesional individuals:

http://www.sistemasagiles.com.ar/trac/wiki/PyAfipWs#ReferenciasComerciales

In fact, the server (including web2py) is being used internally in a
related project for an important network information center.

- I need to implement SOAP protocols defined by others without any chance to
>   change a tiny bit.
>

PySimpleSoap also has some hacks to support this, and you could mimic other
webservices implementations.
In fact, initially I developed it to make a "simulator" of a government
.NET webservice that only published the WSDL:

https://www.sistemasagiles.com.ar/simulador/wsfev1/call/soap?WSDL

for

https://wswhomo.afip.gov.ar/wsfev1/service.asmx?WSDL

(yes, it is not an exact emulation but just to show the point)

Some contributors have sent patches to extend the use cases, and the
underlying XML abstraction layer uses the standard library minidom that
should be enought to ad-hoc support most "esoteric" soap features.


> - I have an unknown number of SOAP clients, most proprietary desktop
>   applications from a random number of ISVs (each with their own bugs). I
>   need to be interoperable with every single one.
>
>
Yes, this is a frequent issue.
I've tested and adapted PySimpleSoap with common ones: .Net, Java, etc.
(there is a wiki page explaining it)
My approach is to adapt internally the library to support the different
soap dialects, and expose a minimal API to use it.
I found this easier than exposing a large API and object model that the
user has to understand and tailor.
Also, I think it is more uniform and the same internal quirks could be used
in other applications by unexperienced users (my next step is to
automatically detect the soap dialect for a seamless operation)


> From my experience rules out any library which supports SOAP among others.
> I
> needed complete control over the complete request/response parsing
> (including
> the ability to process/return invalid SOAP to satisfy specific clients).
>
>
You said the magic words ;-)
The question is what is the experience and what are the use cases of the
user requesting this recommendaton.

PySimpleSOAP is targeted more to users that need a rapid & dynamic
solution, without needing to go too deep on technical details.

The idea is maintaining it codebase as simple and small as possible, so it
could be easily understood by novice users, and even individual
intermediate users could contribute patches. There should be no need to
hire an expert or a consulting firm to use this library for common use
cases (although paid tech support has made possible many complex
enhancements). YMMV
The library implements a SimpleXMLElement object to dynamically abstract
xml manipulation via python objects, and the API is really simple: just
mainly a Client and a Server classes (using python builtin types, dict,
list, etc., to construct even complex element structures, for RPC input and
output parameters).
This were inspired by the PHP SOAP extension, so other goal of this project
is to help with the transition from other programming languages.
Also, this simplified and dynamic approach hepls to lower the memory
consumption and could speed up processing considerably, compared to other
implementations (in some cases, see comment in issue
49<https://code.google.com/p/pysimplesoap/issues/detail?id=49#c3>
)

So far, the project involved around 4 owners, 20 commiters and 9
contributors (not all active right now). It started in 2010 as a spin-off
of the PyAfipWs (electronic invoicing webservices) project circa 2008.
Despite its name, the project is no more just a "simple" implementation, as
support for more advanced features were added over time. So, more or less,
it is now a complete implementation of the most used SOAP protocol specs
(including WSDL parsing and generation).
I'm thinking on changing its name to soap2py to avoid misunderstandings (a
better description would be "lightweight"), and I'm planning on a GUI
visual application (like SoapUI) to help even further prototyping,
development and debugging of webservices apps.
Governance is open and distributed; commit rights are granted to anyone
that sends significative patches, and the GitHub / GoogleCode project sites
has at least two owners and several commiters/contributors.
In fact, I didn't commit many of the new features / python 3 support
changes, and we reunificated a separate fork some years ago.

The library has been integrated to web2py (see the contrib packages), and
is documented in the web2py official book and web2py recipes book (Packt).
The client support several transports (urllib, httplib2, pycurl, etc.) and
the server is WSGI compilant, with sample apps for web2py, django and
possibly others, supporting non-trivial enterprise infrastructures
(propietary proxy auth, webservers, etc.)

It is licenced using LGPLv3 (weak copyleft, GPL compatible, OSI/FSF
approved, can be used in closed commercial projects, etc.) and the user can
choose any later version (so I think contributors agreements are not really
an issue).
BTW, the LGPLv3 is more updated and "internationalized" than other
permisive licences (for example, some sections of the classic MIT/BSD
licences could be considered abusive on some circunstances at least here in
Argentina, AFAIK).

Summary:

Pros:

- maitained by professional software developers (at least me), many
contributors so far
- active community management: unified github/googlecode and relicencing is
not required as it is LGPLv3+
- support for Python 2.6-3.x (mainly tested for 2.7, and less for 3.4 )
- no external dependencies are mandatory (works out of the box with the
python standard library)
- simple API for RPC using only builtin python types for parameters  (dict,
list, str, int, etc.)
- "pythonic" abstraction layer for XML (SimpleXMLElement)
- supports different dialects of SOAP (.NET WCF, Java Axis, etc.)
- everything is dynamic: no need for code generation, artifacts, custom
object model, mappers, etc.
- relative low memory footprint and possible speed-ups due the simple API
and dynamic abstraction model
- small codebase: 5 modules, 4 main classes, no advanced OOP skills required
- comprehensive implementation (including client/server and WSDL parsing /
generation)
- multi-transport (urllib2, httplib2, pycurl) and WSGI-compilant (web2py,
django)
- documented in the project site (wiki), and inside 2 printed books
- installabe through pypi (only the stable version)
- backward compatibility (almost no conflictive API changes between
releases)

Cons (see the open issues list for more info):

- not polished as a silver-bullet (but most use cases will work out of the
box, expect some hacking for special cases)
- "esoteric" rare used XML/SOAP features are not supported by now (ie.
element attributes, but raw request could be used)
- namespaces (complex wsdl parsing support), python 3, etc. are "recent"
additions that need more testing
- missing a simple & automatic object mapping function to expose more
complex structures of simple python types (causes a kind of "impedance
mismatch" with other frameworks that could be easily resolved
instrospectively in the serialization code, this is my next item in my TODO
list)
- contributor/user ratio is low and varying over time (don't expect hard
issues to be resolved fast ouside commercial tech support)
- some internal parts (specially wsdl parsing) needs serious refactoring to
be easier to understand and extend
- a lot of tests needs feedback for the users that sent the issues (some
may even fail due webservice no longer exists or changed)
- development pace is not as fast as it should be (due most important
features are mature enough at least for me, and other libraries could
attract users with more specific needs)
- some important features are only in the development repository, so
they're not yet released in the stable version (I'm planning a new release
ASAP)

Finally, another relevant library not mentioned previously in this thread
is WSME (WebServices made easy), that had a recent release:

http://wsme.readthedocs.org/en/latest/


Hope this help, and sorry for the long mail

Best regards,

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20140510/9b936c4a/attachment.html>

From burak.arslan at arskom.com.tr  Mon May 19 15:40:31 2014
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Mon, 19 May 2014 16:40:31 +0300
Subject: [Soap-Python] soap library for python-3.x
In-Reply-To: <CAPyeU7QfjFYQ8u928=J6TOt3zFGnSfF=KWLdAkd3j4b5+9PZNg@mail.gmail.com>
References: <20140425095615.M32856@cdot.in> <536CE6A1.6000209@oss.schwarz.eu>
 <CAPyeU7QfjFYQ8u928=J6TOt3zFGnSfF=KWLdAkd3j4b5+9PZNg@mail.gmail.com>
Message-ID: <537A09CF.6060803@arskom.com.tr>

Hello All,

And as you may know, I maintain Spyne. I also wrote most of it. Also,
correct me if I'm wrong here, Spyne is the oldest maintained Soap
codebase written in Python. It's also WS-I compliant.

First, this long post won't conclude that Spyne is best and we should
all use it. I'll say something different. Please read on.

I'm sure we all agree that implementing a SOAP library is a huge
undertaking. Implementing SOAP really means implementing Xml Schema,
Wsdl 1.1 Wsdl 2.0 Soap 1.1 and Soap 1.2 standards, both in a client and
server setting.

Implementing daemons in Python is also a minefield. Depending on the
project requirements, you need to use gevent, twisted or WSGI and learn
about quirks of its many implementations etc.

Without a proper abstraction in place, it is very difficult to switch
between these.

Spyne is not just a Soap library anymore, it also became that
abstraction. Because that's what I had fun working on. There's more than
1000 commit difference between 2.10 and 2.11. There's a lot more goodies
in there but lower level efforts make up the bigger part of the 2.11 effort.

So if you go your your own way and re-implement Soap from the ground up,
you'll run into the issues we already ran into, and you'll have to deal
with them just like we had to. Perhaps you'll end up with a more
complete Soap implementation than Spyne, but you'll also have a less
robust RPC codebase than Spyne.

A couple of concrete examples:

1) For an xsd:sequence (the default class declaration method in both
soapbox and spyne) to pass validation, the tags in it must be *in the
same order it's defined in the wsdl document*.

I'm looking at this example and seeing the same naive mistake that we
did in Spyne:

https://github.com/FelixSchwarz/soapbox-bsd/blob/master/examples/xml_complex_types.py

The field order in the sequence is defined by the dict passed to
xsd.ComplexType metaclass. The order in python dicts are *random* and
change according to a wild array of factors, especially now that we have
PYTHONHASHSEED=random as an option. So when you add an innocent new
field to an existing object declaration, be ready to have all cached
wsdl documents invalidated.

See https://github.com/arskom/spyne/pull/313 and
https://github.com/arskom/spyne/pull/343 to see how we solved that
problem. Fixing it in Python 2 wasn't easy!

2) what are your precautions for parsing XML documents from untrusted
sources?

https://github.com/FelixSchwarz/soapbox-bsd/blob/31aff9f5825f1d6520a84bd938663851a45b5a03/soapbox/xsd.py#L859

None, from what I can tell.

This part of spyne documentation is full of security-related xml links:
http://spyne.io/docs/2.10/reference/protocol/xml.html#spyne.protocol.xml._base.XmlDocument

The most famous one: https://en.wikipedia.org/wiki/Billion_laughs

3) Are you using incremental xml generation? Can you produce a 8
gigabyte xml document without having it all in memory with SoapBox?
Apparently not:

https://github.com/FelixSchwarz/soapbox-bsd/blob/31aff9f5825f1d6520a84bd938663851a45b5a03/soapbox/xsd.py#L920

With Spyne 2.11, you can, thanks to lxml's incremental generation api.

I could go on and on.

(The above points also apply to PySimpleSoap but I'm don't want to
compare it with Spyne as PySimpleSoap's code is really naive and
seemingly deliberately so as it says simple right there in the project's
name. I feel the two projects serve two very different audiences. )

So my point is: If you go and make rude statements like this:

On 05/09/14 17:30, Felix Schwarz wrote:
> (Disclaimer: I'm one of the maintainers of "soapbox-bsd".)
>
> I think you should check out soapbox-bsd which is the only real option for
> server-side SOAP in Python: https://github.com/FelixSchwarz/soapbox-bsd

you're not doing open source. (only *real* option? come on, Felix
Schwarz, you shouldn't be so full of yourself)

Open source is about collaboration. What I'm seeing so far is not a
willingness to collaborate but wasteful chest-pounding fed by ignorance
about the delicacies of our craft I'm sadly used to see in corporate
environments.

You may or may not like Spyne, or PySimpleSoap or, soapbox, (or Ladon,
it did Soap with Python last time I looked as well). None of them are
perfect. But you must recognise that 1) everybody will benefit from
unifying these efforts. 2) our lives will be made easier once the
iniatial integration works are done with, because now we're a team.

So here's what I suggest: Let's put our egos aside, look at each other's
code, identify the strengths of each project, make sacrifices and unify 
Soap efforts in Python.

If doing my part will mean doing a git rm -r spyne/protocol/soap or git
rm -r spyne/interface/wsdl and simply import an adapter for SoapBox when
importing spyne.protocol.soap, i'll do it, provided it will result in a
better Soap experience for Spyne users.

So, awaiting your feedback.

Best regards,
Burak



From jurko.gospodnetic at pke.hr  Mon May 26 06:55:34 2014
From: jurko.gospodnetic at pke.hr (=?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?=)
Date: Mon, 26 May 2014 06:55:34 +0200
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <53821039.5030806@pke.hr>
References: <53821039.5030806@pke.hr>
Message-ID: <5382C946.6030608@pke.hr>

[re-posting this to soap at python.org, as Burlak Arslan thought it might 
be useful to the community]

   Hi Burak.

On 25.5.2014. 15:08, Burak Arslan wrote:
> I'm the maintainer of Spyne. Are you aware of soap at python.org? If not,
> making an announcement there would be a nice way to start replacing suds
> with your fork of suds.

   Nope, I was not aware of that mailing list and thanks for point me to
it. :-)

   As for formally taking over suds - I'm heading that way but am not
quite ready to do that officially just yet.

   The fork is readily available, but there are a few more things I'd
like to do before requesting it to be named the official suds successor. 
The main thing that pops to mind is that I still need to take over the 
original project's documentation and I want to set up an automated 
testing environment for the project.


> We can also start making interop testing between Spyne & suds-jurko.
> There used to be a soap client in Spyne but I dropped it in favour of
> suds years ago, so %100 interoperability with suds is important for me.

   I'm trying hard to keep suds-jurko 100% compatible with suds,
including keeping support for Python 2.4.

   There is one place where this suds compatibility got broken - suds
last_sent()/last_received() message getters have been removed. They were 
not really cleanly implemented (the data they returned got processed by 
some but not all registered suds plugins) and I'm planning on 
reimplementing them more cleanly some time in the near future. On the 
other hand, if this proves to be causing you any significant problems - 
the change itself is contained in a single easily revertible commit.

   I'd be most grateful if you could use the fork in any sort of a test
suite you have set up for your project - the more test coverage it gets, 
the better. Especially considering that the original project had not a 
single automated tests. :-D

   I'm working on it in my free time so its sometimes more and sometimes
less active. As for the topics - I've been trying to get the tests set
up before doing any other major work on the project, other than perhaps
looking into some interesting defects & missing features inherited from
the original project that seem to be irking a lot of people.

   There have been a lot of tests added, but the list of ones I realize
are missing seems to be growing even faster. :-D

   Hope you find the fork useful.

   Best regards,
     Jurko Gospodneti?


P.S.

   FYI, here's a rough overview of the project's near term plans:

   Currently I'm working towards having a cleaner setup/test procedure
on different Python platforms and having all the tests runnable using
tox. Still not there yet, but getting closer every day. :-)

   I already implemented the improved last_sent()/last_received()
message getters locally, but did not feel like committing them until
related testing got improved. So that should be done next after the more
complete testing environment is set up.

   I guess, besides looking at some small patches and bug reports that
got collected on the project's BitBucket issue tracker, taking over the
documentation should come after that.


From lupindeterd at gmail.com  Wed May 28 06:56:00 2014
From: lupindeterd at gmail.com (Lupin Deterd)
Date: Wed, 28 May 2014 16:56:00 +1200
Subject: [Soap-Python] suds without internet access[help]
Message-ID: <CAL0mBkSGZtO5puWeoptgwD0vxM5tS+HJw4_DJsu8nWrkKwfAQw@mail.gmail.com>

Hi list,

Good day.

  I'm using suds for accessing SOAP server but it's failling. Same with
this issue unfortunately the suggested work-around isn't working. suds
failed without internet
access<https://mail.python.org/pipermail/soap/2011-May/000453.html>

The problem with suds is that it tries to download from the internet
XMLSchema.xsd without success:

DEBUG:suds.xsd.sxbasic:Import:0xb7808a6cL, importing
ns="http://www.w3.org/2001/XMLSchema",
location="http://www.w3.org/2001/XMLSchema.xsd"
DEBUG:suds.transport.http:opening
(http://www.w3.org/2001/XMLSchema.xsd)Traceback (most recent call
last):.....
urllib2.URLError: <urlopen error timed out>


I am not a full time developer, so my question are:

-> Why does a library like that need to reference an online link?
-> Is there any work-around for this that will work without this suds
client access to internet?


Thanks in advance,
Lupin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20140528/c2e06fd1/attachment.html>

From jurko.gospodnetic at pke.hr  Wed May 28 14:03:36 2014
From: jurko.gospodnetic at pke.hr (=?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?=)
Date: Wed, 28 May 2014 14:03:36 +0200
Subject: [Soap-Python] suds without internet access[help]
In-Reply-To: <CAL0mBkSGZtO5puWeoptgwD0vxM5tS+HJw4_DJsu8nWrkKwfAQw@mail.gmail.com>
References: <CAL0mBkSGZtO5puWeoptgwD0vxM5tS+HJw4_DJsu8nWrkKwfAQw@mail.gmail.com>
Message-ID: <5385D098.3010701@pke.hr>

   Hi Lupin.

On 28.5.2014. 6:56, Lupin Deterd wrote:
> I'm using suds for accessing SOAP server but it's failling. Same with
> this issue unfortunately the suggested work-around isn't working. suds
> failed without internet access
> <https://mail.python.org/pipermail/soap/2011-May/000453.html>
>
> The problem with suds is that it tries to download from the internet
> XMLSchema.xsd without success:
>
> |DEBUG:suds.xsd.sxbasic:Import:0xb7808a6cL,  importing ns="
> http://www.w3.org/2001/XMLSchema",  location="
> http://www.w3.org/2001/XMLSchema.xsd"
> DEBUG:suds.transport.http:opening(http://www.w3.org/2001/XMLSchema.xsd)
> Traceback  (most recent call last):
> .....
> urllib2.URLError:  <urlopen error timed out>|
>
> I am not a full time developer, so my question are:
>
> -> Why does a library like that need to reference an online link?
> -> Is there any work-around for this that will work without this suds
> client access to internet?

   I know there is a less clear solution using some global data in the 
basic suds release, but if you use the suds-jurko fork 
(https://bitbucket.org/jurko/suds, or available on PyPI as suds-jurko), 
you should be able to provide your suds client with such external 
resources locally like this:

> store = suds.store.DocumentStore({
>     "http://www.w3.org/2001/XMLSchema.xsd": xmlSchema_data})
> client = suds.client.Client(my_ws_URL, documentStore=store)


   For more detailed usage examples look through the suds-jurko test 
suite. Some related links:

> https://bitbucket.org/jurko/suds/src/25c1cdbede47d2dbbd18ff4685c3f9f59bd6fe05/tests/test_request_construction.py#cl-483
> https://bitbucket.org/jurko/suds/src/25c1cdbede47d2dbbd18ff4685c3f9f59bd6fe05/tests/test_client.py#cl-718


   Hope this helps.

   Best regards,
     Jurko Gospodneti?



From burak.arslan at arskom.com.tr  Fri May 30 08:43:07 2014
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 30 May 2014 09:43:07 +0300
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <53821039.5030806@pke.hr>
References: <mailman.10254.1400876180.18130.python-list@python.org>
 <roy-F214F1.19572423052014@news.panix.com> <5381AFD8.4050106@pke.hr>
 <5381EB66.8030105@arskom.com.tr> <53821039.5030806@pke.hr>
Message-ID: <5388287B.6090601@arskom.com.tr>



On 25/05/14 18:46, Jurko Gospodneti? wrote:
> I'd be most grateful if you could use the fork in any sort of a test
> suite you have set up for your project - the more test coverage it
> gets, the better. Especially considering that the original project had
> not a single automated tests.

See:

https://spyne.ci.cloudbees.com/job/spyne/PYFLAV=2.7/lastCompletedBuild/testReport/spyne.test.interop.test_suds/TestSuds/

https://github.com/arskom/spyne/blob/master/spyne/test/interop/test_suds.py

Spyne is migrating towards tox (Spyne was there way before tox was 
around) but the suds interop tests are not there yet. So I can't have 
two versions of suds tests that runs against both suds and suds-jurko yet.

But you can run Spyne tests against your suds locally. Just clone Spyne 
repo and edit setup.py to use suds-jurko instead of suds here: 
https://github.com/arskom/spyne/blob/master/setup.py#L344

If you're planning to change the root namespace (e.g. suds => jsuds) I 
can simply copy test_suds.py to test_jsuds.py so both could be tested 
side by side.

I also contemplated taking over suds some time ago but Suds codebase was 
not that adorable last time I looked at it. See: 
http://stackoverflow.com/a/15156236

The fork I mention there is: https://github.com/plq/suds

Lastly, suds is *very* slow, because its XML parsing is pure-python. 
Also, it can't do async because unlike Spyne, transports are not 
pluggable. If, instead of improving suds, you're willing to look at 
Spyne's SOAP client, I can help you much more there. It does do Xml 
Schema parsing but not Wsdl parsing, otherwise it's more or less working.

Good luck with your efforts, you seem to be doing a great job and great 
service to the community.

Best regards,
Burak


From burak.arslan at arskom.com.tr  Fri May 30 10:17:18 2014
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 30 May 2014 11:17:18 +0300
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <53882B7D.7050507@zato.io>
References: <mailman.10254.1400876180.18130.python-list@python.org>
 <roy-F214F1.19572423052014@news.panix.com> <5381AFD8.4050106@pke.hr>
 <5381EB66.8030105@arskom.com.tr> <53821039.5030806@pke.hr>
 <5388287B.6090601@arskom.com.tr> <53882B7D.7050507@zato.io>
Message-ID: <53883E8E.5080705@arskom.com.tr>

On 30/05/14 09:55, Dariusz Suchojad wrote:
> On 05/30/2014 08:43 AM, Burak Arslan wrote:
>
> [About suds]
>
>> Also, it can't do async because unlike Spyne, transports are not
>> pluggable.
> Just for the record - I use suds-jurko asynchronously in Zato, which is
> based on gunicorn/gevent, just fine.

Well, you're correct. Gevent does give you a sync interface on top of an 
async foundation. But when I said async, I was thinking of twisted-like 
event driven programming. I should have said "suds can't be used in an 
event-driven way".

After having heard what Guido said about greenlet (look up his pycon 
2013 keynote), I must have totally erased it from my memory :) And I 
agree with him you know, I won't rely on the insanity of monkeypatching 
the whole stdlib in order to do task switching in userspace: 
https://github.com/python-greenlet/greenlet/tree/master/platform

Which also doesn't invalidate the pluggable transports point. Correct me 
if I'm wrong but last time I looked, you couldn't do Soap over ZeroMQ, 
msgpack or twisted with suds.

I need to admit though: Spyne's client bits are not as complete as I'd 
like. But I hope to eventually offer client support in Spyne that is on 
par with server support. And it just would be so nice if somebody helped 
me with that!

Best regards,
Burak


From jurko.gospodnetic at pke.hr  Fri May 30 10:20:01 2014
From: jurko.gospodnetic at pke.hr (=?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?=)
Date: Fri, 30 May 2014 10:20:01 +0200
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <5388287B.6090601@arskom.com.tr>
References: <mailman.10254.1400876180.18130.python-list@python.org>
 <roy-F214F1.19572423052014@news.panix.com> <5381AFD8.4050106@pke.hr>
 <5381EB66.8030105@arskom.com.tr> <53821039.5030806@pke.hr>
 <5388287B.6090601@arskom.com.tr>
Message-ID: <lm9eve$3lk$1@ger.gmane.org>

   Hi Burak.

On 30.5.2014. 8:43, Burak Arslan wrote:
> If you're planning to change the root namespace (e.g. suds => jsuds) I
> can simply copy test_suds.py to test_jsuds.py so both could be tested
> side by side.

   So far I've been trying to maintain the same namespace so the fork
can be used as an in-place replacement with as little effort required
from the user as possible.


> I also contemplated taking over suds some time ago but Suds codebase was
> not that adorable last time I looked at it. See:
> http://stackoverflow.com/a/15156236

   Yup, I like the term 'not that adorable'. :-D

   I ran into myself a couple of years ago when I needed to write a
Python based SOAP WS client. Nothing better was available, and suds was
the most recommended project to use so I patched it up to work correctly 
where I needed it. Later on I continued working on it - mostly as an 
experiment in maintaining legacy software, implementing automated 
testing/setup/build, Python 2/3 compatibility, useful code-base for 
teaching new hires about programming and team-work, etc. :-)


> The fork I mention there is: https://github.com/plq/suds

   I'll take a look. Can't promise exactly when I'll have enough free
time, but I can port over whatever bug-fixes & patches you need.


> Lastly, suds is *very* slow, because its XML parsing is pure-python.
> Also, it can't do async because unlike Spyne, transports are not
> pluggable. If, instead of improving suds, you're willing to look at
> Spyne's SOAP client, I can help you much more there. It does do Xml
> Schema parsing but not Wsdl parsing, otherwise it's more or less working.

   Yup, I noticed the speed factor. But would not like to tackle that
problem until the correctness can be guaranteed by a solid test suite.
Otherwise, I'm bound to mess stuff up. :-D

   As for the 'pluggable transports', suds does have a Transport concept
and you can write & plug in your own. Whether its Transport interface
allows them to be used asynchronously is another matter, and that is one 
interesting venue to research in the future.

   On the other hand, I know suds itself is not safe to use concurrently
from multiple threads, and I am not even sure if it is completely safe
to use from multiple concurrent processes as well. :-s I think its cache 
folder usage might not be completely safe there.

   As for the Spyne SOAP client, I'll take a look when I can. Although,
I think evolution is much better than revolution when talking about
software design & development :-D and I try to avoid reimplementing
stuff from scratch wherever possible. In general, I find that since
software typically grows into an entity too complex to be held in one
head with all of it details, reimplementing it usually just reshuffles
the cards and trades one set of problems for another.


> Good luck with your efforts, you seem to be doing a great job and great
> service to the community.

   Thanks. Hope it helps someone. :-)


   Best regards,
     Jurko Gospodneti?




From ovnicraft at gmail.com  Fri May 30 14:51:42 2014
From: ovnicraft at gmail.com (Ovnicraft)
Date: Fri, 30 May 2014 07:51:42 -0500
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <5382C946.6030608@pke.hr>
References: <53821039.5030806@pke.hr> <5382C946.6030608@pke.hr>
Message-ID: <CA+16coOLrcU3a0VfO-2HQNsDmpQN=DagH7CcL5t6eq=DTM271g@mail.gmail.com>

On Sun, May 25, 2014 at 11:55 PM, Jurko Gospodneti? <
jurko.gospodnetic at pke.hr> wrote:

> [re-posting this to soap at python.org, as Burlak Arslan thought it might be
> useful to the community]
>
>   Hi Burak.
>
> On 25.5.2014. 15:08, Burak Arslan wrote:
>
>> I'm the maintainer of Spyne. Are you aware of soap at python.org? If not,
>> making an announcement there would be a nice way to start replacing suds
>> with your fork of suds.
>>
>
>   Nope, I was not aware of that mailing list and thanks for point me to
> it. :-)
>
>   As for formally taking over suds - I'm heading that way but am not
> quite ready to do that officially just yet.
>
>   The fork is readily available, but there are a few more things I'd
> like to do before requesting it to be named the official suds successor.
> The main thing that pops to mind is that I still need to take over the
> original project's documentation and I want to set up an automated testing
> environment for the project.
>

IMO your fork is really better that official, i dont think request now is a
technical issue.

If "official site" or name comes to your fork python people interested
could know the real status of library.

We can work in documentation to make it fast :-).

>
>
>  We can also start making interop testing between Spyne & suds-jurko.
>> There used to be a soap client in Spyne but I dropped it in favour of
>> suds years ago, so %100 interoperability with suds is important for me.
>>
>
>   I'm trying hard to keep suds-jurko 100% compatible with suds,
> including keeping support for Python 2.4.
>
>   There is one place where this suds compatibility got broken - suds
> last_sent()/last_received() message getters have been removed. They were
> not really cleanly implemented (the data they returned got processed by
> some but not all registered suds plugins) and I'm planning on
> reimplementing them more cleanly some time in the near future. On the other
> hand, if this proves to be causing you any significant problems - the
> change itself is contained in a single easily revertible commit.
>
>   I'd be most grateful if you could use the fork in any sort of a test
> suite you have set up for your project - the more test coverage it gets,
> the better. Especially considering that the original project had not a
> single automated tests. :-D
>
>   I'm working on it in my free time so its sometimes more and sometimes
> less active. As for the topics - I've been trying to get the tests set
> up before doing any other major work on the project, other than perhaps
> looking into some interesting defects & missing features inherited from
> the original project that seem to be irking a lot of people.
>
>   There have been a lot of tests added, but the list of ones I realize
> are missing seems to be growing even faster. :-D
>
>   Hope you find the fork useful.
>

Thanks for the fork !


The best,

>
>   Best regards,
>     Jurko Gospodneti?
>
>
> P.S.
>
>   FYI, here's a rough overview of the project's near term plans:
>
>   Currently I'm working towards having a cleaner setup/test procedure
> on different Python platforms and having all the tests runnable using
> tox. Still not there yet, but getting closer every day. :-)
>
>   I already implemented the improved last_sent()/last_received()
> message getters locally, but did not feel like committing them until
> related testing got improved. So that should be done next after the more
> complete testing environment is set up.
>
>   I guess, besides looking at some small patches and bug reports that
> got collected on the project's BitBucket issue tracker, taking over the
> documentation should come after that.
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> https://mail.python.org/mailman/listinfo/soap
>



-- 

[image: Cristian Salamea on about.me]

Cristian Salamea
about.me/ovnicraft
    <http://about.me/ovnicraft>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20140530/52644944/attachment.html>

From dsuch at zato.io  Fri May 30 08:55:57 2014
From: dsuch at zato.io (Dariusz Suchojad)
Date: Fri, 30 May 2014 08:55:57 +0200
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <5388287B.6090601@arskom.com.tr>
References: <mailman.10254.1400876180.18130.python-list@python.org>
 <roy-F214F1.19572423052014@news.panix.com> <5381AFD8.4050106@pke.hr>
 <5381EB66.8030105@arskom.com.tr> <53821039.5030806@pke.hr>
 <5388287B.6090601@arskom.com.tr>
Message-ID: <53882B7D.7050507@zato.io>

On 05/30/2014 08:43 AM, Burak Arslan wrote:

[About suds]

> Also, it can't do async because unlike Spyne, transports are not
> pluggable. 

Just for the record - I use suds-jurko asynchronously in Zato, which is
based on gunicorn/gevent, just fine.

I can't say whether the original suds library could have been used
because I didn't really investigate that option, went straight to
suds-jurko.

The only issue I had was that suds-jurko inherited from plain suds
class/client-level caches that had to be worked around by obtaining a
queue of pre-configured number of SOAP clients in their own queues by an
initializing Zato server.

https://github.com/zatosource/zato/blob/master/code/zato-server/src/zato/server/connection/http_soap/outgoing.py#L314

https://github.com/zatosource/zato/blob/master/code/zato-server/src/zato/server/connection/queue.py

So essentially:

- gevent monkey patches everything suds-jurko needs thus making the
latter asynchronous

- Zato creates a queue of client connections

- Users can run suds-jurko in an asynchronous manner

- Everyone is happy :-)

cheers,

-- 
Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python

From dsuch at zato.io  Fri May 30 10:37:59 2014
From: dsuch at zato.io (Dariusz Suchojad)
Date: Fri, 30 May 2014 10:37:59 +0200
Subject: [Soap-Python] How keep Python 3 moving forward - suds & Python 3
In-Reply-To: <53883E8E.5080705@arskom.com.tr>
References: <mailman.10254.1400876180.18130.python-list@python.org>
 <roy-F214F1.19572423052014@news.panix.com> <5381AFD8.4050106@pke.hr>
 <5381EB66.8030105@arskom.com.tr> <53821039.5030806@pke.hr>
 <5388287B.6090601@arskom.com.tr> <53882B7D.7050507@zato.io>
 <53883E8E.5080705@arskom.com.tr>
Message-ID: <53884367.3000408@zato.io>

On 05/30/2014 10:17 AM, Burak Arslan wrote:

> Well, you're correct. Gevent does give you a sync interface on top of an
> async foundation. But when I said async, I was thinking of twisted-like
> event driven programming. I should have said "suds can't be used in an
> event-driven way".
> 
> After having heard what Guido said about greenlet (look up his pycon
> 2013 keynote), I must have totally erased it from my memory :) And I
> agree with him you know, I won't rely on the insanity of monkeypatching
> the whole stdlib in order to do task switching in userspace:
> https://github.com/python-greenlet/greenlet/tree/master/platform
> 
> Which also doesn't invalidate the pluggable transports point. Correct me
> if I'm wrong but last time I looked, you couldn't do Soap over ZeroMQ,
> msgpack or twisted with suds.

Sure, naturally - I've just mentioned it in case one day someone
attempts to find information on whether suds-jurko is
greenlet/gevent-safe, which is a nice way to make an application
asynchronous.

With a caveat on its thread/greenlet-safety - and this can be worked
around by a dedicate pool of connections - this can be done.

cheers,

-- 
Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python