This Page

Quick search

This means you can do better than just adding 'spyne' to your list of
dependencies. Assuming the current version of spyne is 2.4.8,
you can use the following as dependency string:

spyne if you feel adventurous or are willing to work on spyne itself.

spyne<2.99 if you only want backwards-compatible bug fixes and new
features.

spyne<2.5 if you only want backwards-compatible bug fixes.

spyne=2.4.8 if you rather like that version.

We have a policy of pushing to pypi as soon as possible, so be sure to at
least use the second option to prevent things from breaking unexpectedly.

Spyne project uses -alpha -beta and -rc labels to denote unfinished code. We
don’t prefer using separate integers for experimental labels. So for example,
instead of having 2.0.0-alpha47, we’ll have 2.2.5-alpha.

-alpha means unstable code. You may not recognize the project next time
you look at it.

-beta means stable(ish) api, unstable behavior, there are bugs everywhere!
Don’t be upset if some quirks that you rely on disappear.

-rc means it’s been working in production sans issues for some time on
beta-testers’ sites, but we’d still like it to have tested by a few more
people.

These labels apply to the project as a whole. Thus, we won’t tag the whole
project as beta because some new feature is not yet well-tested, but we will
clearly denote experimental code in its documentation.

This is an attempt to make a free-for-all area to display opinions about
possible feature directions of Spyne. Doing it in a text file in the source
repository may not be the best approach for the job, but it should be enough to
at least spark a discussion around this topic.

The following would definitely be nice to have, but are just modules that should
not cause a change in unrelated areas of Spyne.

Support for polymorphism in XML Schema.

Support for the JsonRpc protocol.

Support for the JsonSchema interface document standard.

Support for the Thrift binary protocol.

Support for the Thrift IDL – The Thrift Interface Definition Language.

Uses standard python tools for xml parsing which is good for pure-python
deployments. Spyne uses lxml, due to its excellent xml namespace support and
speed. So Spyne is faster but more difficult to deploy.

Does not support ZeroMQ as transport.

Does not support MessagePack.

Does not support HttpRpc.

Does not do declarative input validation. Traditional (imperative) input
validation is possible via a code injection mechanism similar to Spyne’s
events.

Does not have a Soap client. Spyne does, but it’s not that useful as it does
not parse Wsdl documents.

In fact, Ladon is pure server-side software - the whole idea of supporting a
standard protocol like SOAP is that clients are already out there.

Spyne uses own classes for denoting types, whereas ladon uses Python
callables. This lets ladon api to be simpler, but gives the Spyne api the
power to have declarative restrictions on input types.

Does not test against ws-i.org deliverables for testing soap compatibility.

Does not support parsing and/or modifying protocol or transport headers.

“””
Web Service Made Easy (WSME) is a very easy way to implement webservices in your
python web application. It is originally a rewrite of TGWebServices with focus
on extensibility, framework-independance and better type handling.
“”“

Supports TurboGears

Supports REST+Json, REST+Xml, (a subset of) SOAP and ExtDirect.

Supports type validation.

No client support.

Does not test against ws-i.org deliverables for testing soap compatibility.

Add support for JsonObject protocol. This initial version is expremental.

Add support for MessagePackObject and MessagePackRpc protocols. These
initial versions are expremental.

Make DateTime string format customizable.

Implement TwistedWebResource that exposes an Application instance as a
twisted.web.resource.Resource child.

Remove Deprecated XMLAttribute and XMLAttributeRef. Use XmlAttribute
and XmlAttributeRef instead.

Xml Schema: Add support for the <any> tag.

Add a chapter about Validation to the manual. Thanks Alex!

Interface documents are no longer subclasses of InterfaceBase. It’s up
to the transport to expose the application using a given interface document
standard now. The interface argument to the Application constructor
is now ignored.

Html: Added a very simple lxml-based templating scheme: HtmlPage.

Html: Added row-based tables: They show fields in rows. It’s good for
showing one object per table.

The serialization / deserialization logic was redesigned. Now most of the
serialization-related logic is under the responsibility of the ProtocolBase
children.

Interface generation logic was redesigned. The WSDL logic is separated to
XmlSchema and Wsdl11 classes. ‘add_to_schema’ calls were renamed to just
‘add’ and were moved inside rpclib.interface.xml_schema package.

Interface and Protocol assignment of an rpclib application is now more
explicit. Both are also configurable during instantion. This doesn’t mean
there’s much to configure :)

The rpc decorator now produces static methods. The methods still get an implicit
first argument that holds the service contexts. It’s an instance of the
MethodContext class, and not the ServiceBase (formerly DefinitionBase) class.

The new srpc decorator doesn’t force the methods to have an implicit first
argument.

Fixed fault namespace resolution.

Moved xml constants to rpclib.const.xml_ns

The following changes to soaplib were ported to rpclib’s SOAP/WSDL parts:

duration object is now compatible with Python’s native timedelta.

WSDL: Support for multiple <service> tags in the wsdl (one for each class in the
application)

WSDL: Support for multiple <portType> tags and multiple ports.

WSDL: Support for enumerating exceptions a method can throw was added.

Soaplib is now also protocol agnostic. As it now supports protocols other
than soap (like Rest-minus-the-verbs HttpRpc), it’s renamed to rpclib. This
also means soaplib can now support multiple versions of soap and wsdl
standards.

Mention of xml and soap removed from public api where it’s not directly
related to soap or xml. (e.g. a hook rename: on_method_exception_xml ->
on_method_exception_doc)

Protocol serializers now return iterables instead of complete messages. This
is a first step towards eliminating the need to have the whole message in
memory during processing.

Standalone xsd generation for ClassSerializer objects has been added. This
allows soaplib to be used to define generic XML schemas, without SOAP
artifacts.

Annotation Tags for primitive Models has been added.

The soaplib client has been re-written after having been dropped from
recent releases. It follows the suds API but is based on lxml for better
performance.
WARNING: the soaplib client is not well-tested and future support is tentative
and dependent on community response.