From esiotrot at gmail.com  Wed Dec  1 08:16:35 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Wed, 1 Dec 2010 09:16:35 +0200
Subject: [Soap-Python] Returning an extensible array of key,
	value pairs from a SOAP service
Message-ID: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>

Hi

I'm pretty new to SOAP and soaplib.

Is there a way to have a list of key, value pairs where the values
could be any primitive type, or possibly a structure and return that
from a SOAP service?  So something like a Dict, where I can add to the
entries in the Dict over time without the WSDL changing.  I'm using
the 1.0 branch of soaplib.

I'll need to consume this from a client written in C/C++.

If this is not possible, I'll just stick with a class with predefined
fields and use the ClassSerializer, but it would be nice if I could
avoid the WSDL changing and therefore having to update the client if I
add new fields to the class/dict/whatever.

Thanks.

-- 
Michael Wood <esiotrot at gmail.com>


From dieter at handshake.de  Wed Dec  1 12:29:52 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Wed, 1 Dec 2010 12:29:52 +0100
Subject: [Soap-Python] Returning an extensible array of key,
	value	pairs from a SOAP service
In-Reply-To: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
Message-ID: <19702.12720.709652.272736@gargle.gargle.HOWL>

Michael Wood wrote at 2010-12-1 09:16 +0200:
>I'm pretty new to SOAP and soaplib.
>
>Is there a way to have a list of key, value pairs where the values
>could be any primitive type, or possibly a structure and return that
>from a SOAP service?

A long time ago, I made something like this with
ZSI (and Zope). While this has been a SOAP (based) service,
it was not described by a WSDL but instead used dynamic typing
(each value in the SOAP message used an "xsi:type" attribute to
specify its type).

I expect that you want a WSDL described service.

In principle, WSDL (more precisely "XML-Schema" on which WSDL depends)
supports so called "urtype"s, among others an "anyType" "urtype".
This is however an advanced feature. Frameworks might have
difficulties with it (I met e.g. difficulties with "PyXB", quickly
fixed by its author).

I do know the "soaplib" details -- and wether it can handle
arbitrary types.

  >So something like a Dict, where I can add to the
>entries in the Dict over time without the WSDL changing.  I'm using
>the 1.0 branch of soaplib.
>
>I'll need to consume this from a client written in C/C++.

Then, this client, too, must be able to handle "xsi:type" attributes.
Maybe, this is even a stronger restriction than on the Python side.

>If this is not possible, I'll just stick with a class with predefined
>fields and use the ClassSerializer, but it would be nice if I could
>avoid the WSDL changing and therefore having to update the client if I
>add new fields to the class/dict/whatever.

Maybe, other techniques would be more adequate for you
(e.g. XML-RPC, JSON-RPC, ...)? They are "by nature" dynamic,
not restricted by a static description.



--
Dieter


From esiotrot at gmail.com  Wed Dec  1 13:05:01 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Wed, 1 Dec 2010 14:05:01 +0200
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <19702.12720.709652.272736@gargle.gargle.HOWL>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
	<19702.12720.709652.272736@gargle.gargle.HOWL>
Message-ID: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>

Hi

Thanks for your reply.

On 1 December 2010 13:29, Dieter Maurer <dieter at handshake.de> wrote:
> Michael Wood wrote at 2010-12-1 09:16 +0200:
>>I'm pretty new to SOAP and soaplib.
>>
>>Is there a way to have a list of key, value pairs where the values
>>could be any primitive type, or possibly a structure and return that
>>from a SOAP service?
>
> A long time ago, I made something like this with
> ZSI (and Zope). While this has been a SOAP (based) service,
> it was not described by a WSDL but instead used dynamic typing
> (each value in the SOAP message used an "xsi:type" attribute to
> specify its type).
>
> I expect that you want a WSDL described service.
>
> In principle, WSDL (more precisely "XML-Schema" on which WSDL depends)
> supports so called "urtype"s, among others an "anyType" "urtype".
> This is however an advanced feature. Frameworks might have
> difficulties with it (I met e.g. difficulties with "PyXB", quickly
> fixed by its author).
>
> I do know the "soaplib" details -- and wether it can handle
> arbitrary types.

I see there is an Any serializer and also AnyAsDict, but I don't see
any mention of them in the examples.  Maybe this is what I'm looking
for?

I've just managed to do this:

>>> from soaplib.serializers.primitive import AnyAsDict
>>> from lxml import etree
>>> parent = etree.Element("parent")
>>> s = AnyAsDict()
>>> s.to_xml({"a": ["One"], "b": ["Two"], "c": [3]}, 'tns', parent)
>>> for element in parent.getchildren():
...     print etree.tostring(element)
...
<ns0:retval xmlns:ns0="tns"><a>One</a><c>3</c><b>Two</b></ns0:retval>
>>> print s.from_xml(parent.getchildren()[0])
{'a': ['One'],'c': ['3'],'b': ['Two']}
>>>

Does that look about right?

> ?>So something like a Dict, where I can add to the
>>entries in the Dict over time without the WSDL changing. ?I'm using
>>the 1.0 branch of soaplib.
>>
>>I'll need to consume this from a client written in C/C++.
>
> Then, this client, too, must be able to handle "xsi:type" attributes.
> Maybe, this is even a stronger restriction than on the Python side.

Yes, it's definitely more restrictive than the Python side.  I don't
know if it can handle xsi:type attributes.

>>If this is not possible, I'll just stick with a class with predefined
>>fields and use the ClassSerializer, but it would be nice if I could
>>avoid the WSDL changing and therefore having to update the client if I
>>add new fields to the class/dict/whatever.
>
> Maybe, other techniques would be more adequate for you
> (e.g. XML-RPC, JSON-RPC, ...)? They are "by nature" dynamic,
> not restricted by a static description.

Thanks for the suggestions.  I think I'm stuck with SOAP for the
moment, but perhaps something else will be better for a future
version.

Regards,
Michael

-- 
Michael Wood <esiotrot at gmail.com>


From tseaver at palladion.com  Wed Dec  1 13:12:31 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 01 Dec 2010 07:12:31 -0500
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <19702.12720.709652.272736@gargle.gargle.HOWL>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
	<19702.12720.709652.272736@gargle.gargle.HOWL>
Message-ID: <id5e3g$fmc$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/2010 06:29 AM, Dieter Maurer wrote:
> Michael Wood wrote at 2010-12-1 09:16 +0200:
>> I'm pretty new to SOAP and soaplib.
>>
>> Is there a way to have a list of key, value pairs where the values
>> could be any primitive type, or possibly a structure and return that
>>from a SOAP service?
> 
> A long time ago, I made something like this with
> ZSI (and Zope). While this has been a SOAP (based) service,
> it was not described by a WSDL but instead used dynamic typing
> (each value in the SOAP message used an "xsi:type" attribute to
> specify its type).
> 
> I expect that you want a WSDL described service.
> 
> In principle, WSDL (more precisely "XML-Schema" on which WSDL depends)
> supports so called "urtype"s, among others an "anyType" "urtype".
> This is however an advanced feature. Frameworks might have
> difficulties with it (I met e.g. difficulties with "PyXB", quickly
> fixed by its author).
> 
> I do know the "soaplib" details -- and wether it can handle
> arbitrary types.
> 
>   >So something like a Dict, where I can add to the
>> entries in the Dict over time without the WSDL changing.  I'm using
>> the 1.0 branch of soaplib.
>>
>> I'll need to consume this from a client written in C/C++.
> 
> Then, this client, too, must be able to handle "xsi:type" attributes.
> Maybe, this is even a stronger restriction than on the Python side.
> 
>> If this is not possible, I'll just stick with a class with predefined
>> fields and use the ClassSerializer, but it would be nice if I could
>> avoid the WSDL changing and therefore having to update the client if I
>> add new fields to the class/dict/whatever.
> 
> Maybe, other techniques would be more adequate for you
> (e.g. XML-RPC, JSON-RPC, ...)? They are "by nature" dynamic,
> not restricted by a static description.

You can define a method in soaplib as returnning 'Array(Any)'.  Whether
a given client can handle that or not is a separate issue.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz2O68ACgkQ+gerLs4ltQ537gCfderHzuqJFVamg0aCyY233MGq
fRoAniT5+BQMx4S3FynArz+r6JhbtVij
=w7U1
-----END PGP SIGNATURE-----



From tseaver at palladion.com  Wed Dec  1 13:12:37 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 01 Dec 2010 07:12:37 -0500
Subject: [Soap-Python] soaplib:  WSDL -> Python mapping issues
Message-ID: <id5e3l$fmc$2@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm working on implementing a standard service (WSRP 1.0), where the
WSDL for types / interfaces / messages is already mandated by the
specification[1][2][3].  I have a version which works with suds, but
which is rejected by the Java clients because the generated WSDL doesn't
match the spec.

I tried overriding the application to hard-wire the returned WSDL:  the
Java clients would then fail in executing the first method, because the
messages it returns don't match the spec:  they contain an extra wrapper
element for the response type.

Has anyone run into similar issues trying to implement a "fixed" WSDL
specification with soaplib?  I know that ZSI had support for generating
both client and server stubs from a given WSDL document -- perhaps I
need to use ZSI instead.


[1]
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_types.xsd

[2]
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_interfaces.wsdl


[3]
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz2O7UACgkQ+gerLs4ltQ4jdwCgxxYGfyOX+EdgVrWRvIWS6RuI
dnsAoKnZzdxBeF1094QHX4mzU7xKMQl1
=TTaw
-----END PGP SIGNATURE-----



From esiotrot at gmail.com  Wed Dec  1 13:50:17 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Wed, 1 Dec 2010 14:50:17 +0200
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <id5e3g$fmc$1@dough.gmane.org>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
	<19702.12720.709652.272736@gargle.gargle.HOWL>
	<id5e3g$fmc$1@dough.gmane.org>
Message-ID: <AANLkTi=HgpsFprP1m_+kgu6JN9J6wbL9RvshH87LASiz@mail.gmail.com>

On 1 December 2010 14:12, Tres Seaver <tseaver at palladion.com> wrote:
[...]
> You can define a method in soaplib as returnning 'Array(Any)'. ?Whether
> a given client can handle that or not is a separate issue.

OK thanks, I'll give it a try and see what the client makes of it.

-- 
Michael Wood <esiotrot at gmail.com>


From bradallen137 at gmail.com  Wed Dec  1 14:38:59 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Wed, 1 Dec 2010 07:38:59 -0600
Subject: [Soap-Python] soaplib: WSDL -> Python mapping issues
In-Reply-To: <id5e3l$fmc$2@dough.gmane.org>
References: <id5e3l$fmc$2@dough.gmane.org>
Message-ID: <AANLkTimhOhN0uv8sNrPv4ckHvH6zXiz_4AhTVOaEj5MO@mail.gmail.com>

I'd like for soaplib to be able to also support fixed WSDL; today
we'll evaluate how much effort would be involved and how we might go
about it.

On Wed, Dec 1, 2010 at 6:12 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm working on implementing a standard service (WSRP 1.0), where the
> WSDL for types / interfaces / messages is already mandated by the
> specification[1][2][3]. ?I have a version which works with suds, but
> which is rejected by the Java clients because the generated WSDL doesn't
> match the spec.
>
> I tried overriding the application to hard-wire the returned WSDL: ?the
> Java clients would then fail in executing the first method, because the
> messages it returns don't match the spec: ?they contain an extra wrapper
> element for the response type.
>
> Has anyone run into similar issues trying to implement a "fixed" WSDL
> specification with soaplib? ?I know that ZSI had support for generating
> both client and server stubs from a given WSDL document -- perhaps I
> need to use ZSI instead.
>
>
> [1]
> http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_types.xsd
>
> [2]
> http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_interfaces.wsdl
>
>
> [3]
> http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl
>
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver ? ? ? ? ?+1 540-429-0999 ? ? ? ? ?tseaver at palladion.com
> Palladion Software ? "Excellence by Design" ? ?http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkz2O7UACgkQ+gerLs4ltQ4jdwCgxxYGfyOX+EdgVrWRvIWS6RuI
> dnsAoKnZzdxBeF1094QHX4mzU7xKMQl1
> =TTaw
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From voloviny at gmail.com  Wed Dec  1 15:43:30 2010
From: voloviny at gmail.com (voloviny)
Date: Wed, 1 Dec 2010 15:43:30 +0100
Subject: [Soap-Python] soaplib document/literal
Message-ID: <AANLkTik7uLVZRM6t1ZcSa12CO7mcWs0DoQ_LggAyvTE2@mail.gmail.com>

hi, i am a new soaplib (1.0.0) user,

soaplib generates wsdl with style and encoding specified as document/literal
soaplib successfully accepts document/literal messages
soaplib generates messages with type attribute (document/encoded)
so what style and encoding is soaplib using?
am i missing something?

thanks for your answers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101201/8b378803/attachment.html>

From chris at sydneysys.com  Wed Dec  1 16:10:21 2010
From: chris at sydneysys.com (Chris Austin)
Date: Wed, 1 Dec 2010 09:10:21 -0600
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
Message-ID: <AANLkTimii8rEABFWDhoNOR5wP1UFOhTVfvxSf3_wV2RF@mail.gmail.com>

Hi Micheal,

Have you tried the Any or AnyAsDict type?  It will allow you to send
unstructured xml.

On Wed, Dec 1, 2010 at 1:16 AM, Michael Wood <esiotrot at gmail.com> wrote:

> Hi
>
> I'm pretty new to SOAP and soaplib.
>
> Is there a way to have a list of key, value pairs where the values
> could be any primitive type, or possibly a structure and return that
> from a SOAP service?  So something like a Dict, where I can add to the
> entries in the Dict over time without the WSDL changing.  I'm using
> the 1.0 branch of soaplib.
>
> I'll need to consume this from a client written in C/C++.
>
> If this is not possible, I'll just stick with a class with predefined
> fields and use the ClassSerializer, but it would be nice if I could
> avoid the WSDL changing and therefore having to update the client if I
> add new fields to the class/dict/whatever.
>
> Thanks.
>
> --
> Michael Wood <esiotrot at gmail.com>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101201/66a51f88/attachment.html>

From esiotrot at gmail.com  Wed Dec  1 17:29:03 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Wed, 1 Dec 2010 18:29:03 +0200
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <AANLkTimii8rEABFWDhoNOR5wP1UFOhTVfvxSf3_wV2RF@mail.gmail.com>
References: <AANLkTi=3hNtDGb67Dz6X-kOAv8o7Y_0ss5cKs=m5Tn20@mail.gmail.com>
	<AANLkTimii8rEABFWDhoNOR5wP1UFOhTVfvxSf3_wV2RF@mail.gmail.com>
Message-ID: <AANLkTimt3Dk0Y0Pgr0RSsNBhNbGCAW3_D0AsSe6G9QD6@mail.gmail.com>

Hi Chris

Thanks for your reply.

On 1 December 2010 17:10, Chris Austin <chris at sydneysys.com> wrote:
> Hi Micheal,
>
> Have you tried the Any or AnyAsDict type? ?It will allow you to send
> unstructured xml.

I've found the AnyAsDict serializer and will try it out.  Haven't had
a chance yet to see what my client code does with it.

-- 
Michael Wood <esiotrot at gmail.com>


From dieter at handshake.de  Thu Dec  2 07:56:44 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Thu, 2 Dec 2010 07:56:44 +0100
Subject: [Soap-Python] soaplib:  WSDL -> Python mapping issues
In-Reply-To: <id5e3l$fmc$2@dough.gmane.org>
References: <id5e3l$fmc$2@dough.gmane.org>
Message-ID: <19703.17196.850218.103316@gargle.gargle.HOWL>

Tres Seaver wrote at 2010-12-1 07:12 -0500:
> ...
>Has anyone run into similar issues trying to implement a "fixed" WSDL
>specification with soaplib?  I know that ZSI had support for generating
>both client and server stubs from a given WSDL document -- perhaps I
>need to use ZSI instead.

Should you be unable to solve the problem with "soaplib", then
maybe "dm.zope.wsdl_suds" might be helpful.

It is using "suds" for the "python <-> XML-schema" conversions
and Zope[2] as application server.



--
Dieter


From dieter at handshake.de  Thu Dec  2 08:01:16 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Thu, 2 Dec 2010 08:01:16 +0100
Subject: [Soap-Python] Returning an extensible array of key,
	value	pairs from a SOAP service
In-Reply-To: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
References: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
Message-ID: <19703.17468.954810.367015@gargle.gargle.HOWL>

Michael Wood wrote at 2010-12-1 14:05 +0200:
> ...
>>>> s = AnyAsDict()
>>>> s.to_xml({"a": ["One"], "b": ["Two"], "c": [3]}, 'tns', parent)
>>>> for element in parent.getchildren():
>...     print etree.tostring(element)
>...
><ns0:retval xmlns:ns0="tns"><a>One</a><c>3</c><b>Two</b></ns0:retval>
>>>> print s.from_xml(parent.getchildren()[0])
>{'a': ['One'],'c': ['3'],'b': ['Two']}

As you can see, you have lost type information: the integer "3"
has been converted into the string "'3'".

When types are important for your client sides, then this is likely
not good enough.



--
Dieter


From esiotrot at gmail.com  Thu Dec  2 11:41:25 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Thu, 2 Dec 2010 12:41:25 +0200
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <19703.17468.954810.367015@gargle.gargle.HOWL>
References: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
	<19703.17468.954810.367015@gargle.gargle.HOWL>
Message-ID: <AANLkTinS45pfkft5nx_irxT9DKDDrzcUx2pQx9_iuM_A@mail.gmail.com>

Hi Dieter

On 2 December 2010 09:01, Dieter Maurer <dieter at handshake.de> wrote:
> Michael Wood wrote at 2010-12-1 14:05 +0200:
>> ...
>>>>> s = AnyAsDict()
>>>>> s.to_xml({"a": ["One"], "b": ["Two"], "c": [3]}, 'tns', parent)
>>>>> for element in parent.getchildren():
>>... ? ? print etree.tostring(element)
>>...
>><ns0:retval xmlns:ns0="tns"><a>One</a><c>3</c><b>Two</b></ns0:retval>
>>>>> print s.from_xml(parent.getchildren()[0])
>>{'a': ['One'],'c': ['3'],'b': ['Two']}
>
> As you can see, you have lost type information: the integer "3"
> has been converted into the string "'3'".

Good point.  I didn't notice yesterday.

> When types are important for your client sides, then this is likely
> not good enough.

Thanks.

Is there perhaps a way to retain the type information while using Any
or AnyAsDict?

For the moment I'm just ignoring the extensibility nice-to-have and
using the ClassSerializer.

-- 
Michael Wood <esiotrot at gmail.com>


From burak.arslan at arskom.com.tr  Thu Dec  2 12:12:47 2010
From: burak.arslan at arskom.com.tr (burak.arslan at arskom.com.tr)
Date: Thu, 02 Dec 2010 13:12:47 +0200
Subject: [Soap-Python]
	=?utf-8?q?Returning_an_extensible_array_of_key=2C?=
	=?utf-8?q?=09value=09pairs_from_a_SOAP_service?=
In-Reply-To: <19703.17468.954810.367015@gargle.gargle.HOWL>
References: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
	<19703.17468.954810.367015@gargle.gargle.HOWL>
Message-ID: <123dfdc1fe6b10e7604acc5e2bbc5c01@arskom.com.tr>

 On Thu, 2 Dec 2010 08:01:16 +0100, "Dieter Maurer" 
 <dieter at handshake.de> wrote:
> Michael Wood wrote at 2010-12-1 14:05 +0200:
>> ...
>>>>> s = AnyAsDict()
>>>>> s.to_xml({"a": ["One"], "b": ["Two"], "c": [3]}, 'tns', parent)
>>>>> for element in parent.getchildren():
>>...     print etree.tostring(element)
>>...
>><ns0:retval xmlns:ns0="tns"><a>One</a><c>3</c><b>Two</b></ns0:retval>
>>>>> print s.from_xml(parent.getchildren()[0])
>>{'a': ['One'],'c': ['3'],'b': ['Two']}
>
> As you can see, you have lost type information: the integer "3"
> has been converted into the string "'3'".
>
> When types are important for your client sides, then this is likely
> not good enough.
>

 http://codespeak.net/lxml/objectify.html#python-data-types

>>> from lxml import objectify
>>> root = objectify.fromstring("<root><a>test</a><b>5</b></root>")
>>> root.a
 'test'
>>> root.a.pyval
 'test'
>>> root.b
 5
>>> root.b.text
 '5'
>>> root.b.pyval
 5

 look at doing it with a schema if you want to avoid guesswork.

 http://codespeak.net/lxml/objectify.html#asserting-a-schema

 hth
 burak


>
>
> --
> Dieter
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap



From esiotrot at gmail.com  Thu Dec  2 12:38:47 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Thu, 2 Dec 2010 13:38:47 +0200
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <123dfdc1fe6b10e7604acc5e2bbc5c01@arskom.com.tr>
References: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
	<19703.17468.954810.367015@gargle.gargle.HOWL>
	<123dfdc1fe6b10e7604acc5e2bbc5c01@arskom.com.tr>
Message-ID: <AANLkTimSDGqOW6iysP3b0CrE6JE7A53K66j+-JBJXdhy@mail.gmail.com>

Hi burak

On 2 December 2010 13:12,  <burak.arslan at arskom.com.tr> wrote:
[...]
> http://codespeak.net/lxml/objectify.html#python-data-types
>
>>>> from lxml import objectify
>>>> root = objectify.fromstring("<root><a>test</a><b>5</b></root>")
>>>> root.a
> 'test'
>>>> root.a.pyval
> 'test'
>>>> root.b
> 5
>>>> root.b.text
> '5'
>>>> root.b.pyval
> 5
>
> look at doing it with a schema if you want to avoid guesswork.
>
> http://codespeak.net/lxml/objectify.html#asserting-a-schema

Interesting.  But the client is C++, so not sure I can use that :)

Thanks.

-- 
Michael Wood <esiotrot at gmail.com>


From chris at sydneysys.com  Thu Dec  2 16:26:03 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 2 Dec 2010 09:26:03 -0600
Subject: [Soap-Python] Returning an extensible array of key,
 value pairs from a SOAP service
In-Reply-To: <AANLkTimSDGqOW6iysP3b0CrE6JE7A53K66j+-JBJXdhy@mail.gmail.com>
References: <AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>
	<19703.17468.954810.367015@gargle.gargle.HOWL>
	<123dfdc1fe6b10e7604acc5e2bbc5c01@arskom.com.tr>
	<AANLkTimSDGqOW6iysP3b0CrE6JE7A53K66j+-JBJXdhy@mail.gmail.com>
Message-ID: <AANLkTim_CtO_1xi7Uw+qbUvPs+HmTDD+nWfDqvisUcr6@mail.gmail.com>

Hi Burak,

Good to see that you are still around for the time being.  I just have a
quick question for you if you'd please.

It looks like soaplib does not create a port for each separate service
(DefinitionBase).  Based on a quick review of the wsdl and spec it doesn't
look to explicitly require it but it seems that quite a few soap services do
indeed do create a port per service.

I'm working on providing this functionality now but, I was wondering if you
looked into this previously and if you have any thoughts on the matter.

Thanks
Chris

On Thu, Dec 2, 2010 at 5:38 AM, Michael Wood <esiotrot at gmail.com> wrote:

> Hi burak
>
> On 2 December 2010 13:12,  <burak.arslan at arskom.com.tr> wrote:
> [...]
> > http://codespeak.net/lxml/objectify.html#python-data-types
> >
> >>>> from lxml import objectify
> >>>> root = objectify.fromstring("<root><a>test</a><b>5</b></root>")
> >>>> root.a
> > 'test'
> >>>> root.a.pyval
> > 'test'
> >>>> root.b
> > 5
> >>>> root.b.text
> > '5'
> >>>> root.b.pyval
> > 5
> >
> > look at doing it with a schema if you want to avoid guesswork.
> >
> > http://codespeak.net/lxml/objectify.html#asserting-a-schema
>
> Interesting.  But the client is C++, so not sure I can use that :)
>
> Thanks.
>
> --
> Michael Wood <esiotrot at gmail.com>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101202/d3d153fd/attachment.html>

From dieter at handshake.de  Fri Dec  3 08:36:23 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Fri, 3 Dec 2010 08:36:23 +0100
Subject: [Soap-Python] soaplib document/literal
In-Reply-To: <AANLkTik7uLVZRM6t1ZcSa12CO7mcWs0DoQ_LggAyvTE2@mail.gmail.com>
References: <AANLkTik7uLVZRM6t1ZcSa12CO7mcWs0DoQ_LggAyvTE2@mail.gmail.com>
Message-ID: <19704.40439.910196.160086@gargle.gargle.HOWL>

voloviny wrote at 2010-12-1 15:43 +0100:
>soaplib generates wsdl with style and encoding specified as document/literal

SOAP supports various interaction styles: e.g. "literal" and "rpc".

All web services I have seen so far (not that many) use
"literal" even when they intend "rpc" usage.

>soaplib successfully accepts document/literal messages

I highly expect that all clients will do that -- as it is apparently
the standard way.
The server will when the WSDL tells you it should.

>soaplib generates messages with type attribute (document/encoded)

When I understand this correctly (I have never seen "document/encoded"
in a message) than this specifies how values are encoded.
The default is the encoding specified in connection with XML-Schema.

I highly expect that "soaplib" will use the standard encoding.
Again, all clients should understand it.

>so what style and encoding is soaplib using?

The ones, the generated WSDL tells you it is using ;-)


>am i missing something?

I have the feeling that you are interested in implementation details.

You might switch focus and ask questions of the form:
do the clients I want (or have) to support understand the generated
WSDL and can use the corresponding services.

As mentioned above, it is highly unlikely that problems
will arise from the style or encoding "soaplib" is using.


Implementation details can also be interesting -- once you have
a deep understanding...



--
Dieter


From voloviny at gmail.com  Fri Dec  3 10:19:34 2010
From: voloviny at gmail.com (voloviny)
Date: Fri, 3 Dec 2010 10:19:34 +0100
Subject: [Soap-Python] soaplib document/literal
In-Reply-To: <19704.40439.910196.160086@gargle.gargle.HOWL>
References: <AANLkTik7uLVZRM6t1ZcSa12CO7mcWs0DoQ_LggAyvTE2@mail.gmail.com>
	<19704.40439.910196.160086@gargle.gargle.HOWL>
Message-ID: <AANLkTimDObs7GjQ2a9zt2M_FXXOMyaZ1LW3m=DbhQx9x@mail.gmail.com>

thanks for your answers

actually i am using soaplib server-side
soaplib generates wsdl which specifies document/literal (style/use)

soap client (VS 2008 .net generated) sends document/literal messages such
as:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <Hello xmlns="aaa">
            <text>hello</text>
        </Hello>
    </s:Body>
</s:Envelope>


... and soaplib responds with (document/encoded?):

<?xml version='1.0' encoding='utf-8'?>
<senv:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
xmlns:plink="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:senc="
http://schemas.xmlsoap.org/soap/encoding/" xmlns:s1="aaa" xmlns:s0="bbb"
xmlns:s12env="http://www.w3.org/2003/05/soap-envelope/" xmlns:s12enc="
http://www.w3.org/2003/05/soap-encoding/" xmlns:xs="
http://www.w3.org/2001/XMLSchema" xmlns:wsdl="
http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xmlns:senv="
http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="
http://schemas.xmlsoap.org/wsdl/soap/">
    <senv:Header/>
    <senv:Body>
        <s0:HelloResponse>
            <s0:HelloResult>
                <s0:string xsi:type="xs:string">hello</s0:string>
                <s0:string xsi:type="xs:string">olleh</s0:string>
            </s0:HelloResult>
        </s0:HelloResponse>
    </senv:Body>
</senv:Envelope>


called operation (Hello) is specified as:

<wsdl:operation name="Hello">
    <soap:operation soapAction="Hello" style="document"/>
    <wsdl:input name="Hello">
        <soap:body use="literal"/>
    </wsdl:input>
    <wsdl:output name="HelloResponse">
        <soap:body use="literal"/>
    </wsdl:output>
</wsdl:operation>


everything is working fine (client accepts response message) ...
but the question is ... why is soaplib breaking the contract defined in
wsdl?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101203/818ad125/attachment.html>

From dieter at handshake.de  Fri Dec  3 10:43:06 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Fri, 3 Dec 2010 10:43:06 +0100
Subject: [Soap-Python] soaplib document/literal
In-Reply-To: <AANLkTimDObs7GjQ2a9zt2M_FXXOMyaZ1LW3m=DbhQx9x@mail.gmail.com>
References: <AANLkTimDObs7GjQ2a9zt2M_FXXOMyaZ1LW3m=DbhQx9x@mail.gmail.com>
Message-ID: <19704.48042.60160.828754@gargle.gargle.HOWL>

voloviny wrote at 2010-12-3 10:19 +0100:
> ...
>... and soaplib responds with (document/encoded?):
>
><?xml version='1.0' encoding='utf-8'?>
><senv:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
>xmlns:plink="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
>xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:senc="
>http://schemas.xmlsoap.org/soap/encoding/" xmlns:s1="aaa" xmlns:s0="bbb"
>xmlns:s12env="http://www.w3.org/2003/05/soap-envelope/" xmlns:s12enc="
>http://www.w3.org/2003/05/soap-encoding/" xmlns:xs="
>http://www.w3.org/2001/XMLSchema" xmlns:wsdl="
>http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="
>http://www.w3.org/2001/XMLSchema-instance" xmlns:senv="
>http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="
>http://schemas.xmlsoap.org/wsdl/soap/">
>    <senv:Header/>
>    <senv:Body>
>        <s0:HelloResponse>
>            <s0:HelloResult>
>                <s0:string xsi:type="xs:string">hello</s0:string>
>                <s0:string xsi:type="xs:string">olleh</s0:string>
>            </s0:HelloResult>
>        </s0:HelloResponse>
>    </senv:Body>
></senv:Envelope>

Where do you see "document/encoded"?

I can see one redundant "encoding='utf-8'" (it specifies the default)
and several unused namespace declarations for "encoding" (in some
variety). All of which is harmless (though not strictly necessary).

>called operation (Hello) is specified as:
>
><wsdl:operation name="Hello">
>    <soap:operation soapAction="Hello" style="document"/>
>    <wsdl:input name="Hello">
>        <soap:body use="literal"/>
>    </wsdl:input>
>    <wsdl:output name="HelloResponse">
>        <soap:body use="literal"/>
>    </wsdl:output>
></wsdl:operation>
>
>
>everything is working fine (client accepts response message) ...
>but the question is ... why is soaplib breaking the contract defined in
>wsdl?

Does it?

I see only the use of freedom granted by the various specifications.

For example:

  XML-Names requires that each used namespace prefix has an associated
  definition. But it does not forbid to define unused namespaces.

  XML uses "encoding='utf-8'" as the default but does not forbid
  to specify it explicitely.



--
Dieter


From burak.arslan at arskom.com.tr  Fri Dec  3 11:38:52 2010
From: burak.arslan at arskom.com.tr (burak.arslan at arskom.com.tr)
Date: Fri, 03 Dec 2010 12:38:52 +0200
Subject: [Soap-Python] Returning an extensible array of key,
	value pairs  from a SOAP service
In-Reply-To: <AANLkTim_CtO_1xi7Uw+qbUvPs+HmTDD+nWfDqvisUcr6@mail.gmail.com>
References: "<AANLkTinW9Tg7N8QiG_jMv=HWF+o7cqYL+pnUmftjNBz2@mail.gmail.com>	<19703.17468.954810.367015@gargle.gargle.HOWL>	<123dfdc1fe6b10e7604acc5e2bbc5c01@arskom.com.tr>"
	<AANLkTimSDGqOW6iysP3b0CrE6JE7A53K66j+-JBJXdhy@mail.gmail.com>
	<AANLkTim_CtO_1xi7Uw+qbUvPs+HmTDD+nWfDqvisUcr6@mail.gmail.com>
Message-ID: <13a719157cfb1fd99310c6818f87db7d@arskom.com.tr>

 On Thu, 2 Dec 2010 09:26:03 -0600, Chris Austin <chris at sydneysys.com> 
 wrote:
> Hi Burak,
>
> Good to see that you are still around for the time being. ?I just
> have a quick question for you if you'd please.
>
> It looks like soaplib does not create a port for
> each?separate?service (DefinitionBase). ?Based on a quick review of
> the wsdl and spec it doesn't look to explicitly require it but it
> seems that quite a few soap services do indeed do create a port per
> service. ?
>
> I'm working on providing this?functionality?now but, I was wondering
> if you looked into this previously and if you have any thoughts on 
> the
> matter.
>

 no, never looked at it. once the new soaplib wsdl generator got through 
 ws-i test, i was done with it :)

> Thanks
> Chris
>
> On Thu, Dec 2, 2010 at 5:38 AM, Michael Wood  wrote:
>  Hi burak
>
>  On 2 December 2010 13:12, ? wrote:
>  [...]
>
>> http://codespeak.net/lxml/objectify.html#python-data-types [3]
>  >
>  >>>> from lxml import objectify
>  >>>> root = objectify.fromstring("test5")
>  >>>> root.a
>  > 'test'
>  >>>> root.a.pyval
>  > 'test'
>  >>>> root.b
>  > 5
>  >>>> root.b.text
>  > '5'
>  >>>> root.b.pyval
>  > 5
>  >
>  > look at doing it with a schema if you want to avoid guesswork.
>  >
>  > http://codespeak.net/lxml/objectify.html#asserting-a-schema [4]
>
>  Interesting. ?But the client is C++, so not sure I can use that :)
>
>  Thanks.
>
>  --
>  Michael Wood
>  _______________________________________________
>
> Soap mailing list
>  Soap at python.org [6]
>  http://mail.python.org/mailman/listinfo/soap [7]
>
>
>
> Links:
> ------
> [1] mailto:esiotrot at gmail.com
> [2] mailto:burak.arslan at arskom.com.tr
> [3] http://codespeak.net/lxml/objectify.html#python-data-types
> [4] http://codespeak.net/lxml/objectify.html#asserting-a-schema
> [5] mailto:esiotrot at gmail.com
> [6] mailto:Soap at python.org
> [7] http://mail.python.org/mailman/listinfo/soap



From bradallen137 at gmail.com  Sat Dec  4 15:32:29 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 4 Dec 2010 08:32:29 -0600
Subject: [Soap-Python] soaplib: WSDL -> Python mapping issues
In-Reply-To: <19703.17196.850218.103316@gargle.gargle.HOWL>
References: <id5e3l$fmc$2@dough.gmane.org>
	<19703.17196.850218.103316@gargle.gargle.HOWL>
Message-ID: <AANLkTikV3u4+NBTxF3PbGRe-vY5MDg0vBsOdvr7Vrk2H@mail.gmail.com>

Status update: This issue has delayed the soaplib 2.0 beta release.
Chris Austin  is working on fixes related to WSDL generation
(specifically involving multiple services and ports); hopefully the
problem can be solved without adding support for fixed WSDL, which is
a bigger project we'd like to save for later.

On Thu, Dec 2, 2010 at 12:56 AM, Dieter Maurer <dieter at handshake.de> wrote:
> Tres Seaver wrote at 2010-12-1 07:12 -0500:
>> ...
>>Has anyone run into similar issues trying to implement a "fixed" WSDL
>>specification with soaplib? ?I know that ZSI had support for generating
>>both client and server stubs from a given WSDL document -- perhaps I
>>need to use ZSI instead.
>
> Should you be unable to solve the problem with "soaplib", then
> maybe "dm.zope.wsdl_suds" might be helpful.
>
> It is using "suds" for the "python <-> XML-schema" conversions
> and Zope[2] as application server.
>
>
>
> --
> Dieter
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From cmcgraw at datasyncorp.com  Fri Dec  3 23:18:28 2010
From: cmcgraw at datasyncorp.com (Chris McGraw)
Date: Fri, 3 Dec 2010 16:18:28 -0600 (CST)
Subject: [Soap-Python] Soaplib on pypi
In-Reply-To: <1320141028.52534.1291414700423.JavaMail.root@mailbox1>
Message-ID: <2088279944.52536.1291414708455.JavaMail.root@mailbox1>

Hello,
  I just encountered an issue with easy-install and soaplib (specifically v0.8.1, but I see it's probably affecting all versions).  It appears the project has been renamed on github, and consequently the URL's for downloading have changed. The url that was http://github.com/downloads/arskom/soaplib/soaplib-0.8.1.tar should now be https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar.

Thanks,
Chris McGraw


----------------------
Chris McGraw
DataSync Engineering & Network Operations
605.553.8581




From bradallen137 at gmail.com  Sat Dec  4 15:50:10 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sat, 4 Dec 2010 08:50:10 -0600
Subject: [Soap-Python] Soaplib on pypi
In-Reply-To: <2088279944.52536.1291414708455.JavaMail.root@mailbox1>
References: <1320141028.52534.1291414700423.JavaMail.root@mailbox1>
	<2088279944.52536.1291414708455.JavaMail.root@mailbox1>
Message-ID: <AANLkTimAFj5n=HNwAcVQxZFMOv_FnN5jb0shsxqwmJ3F@mail.gmail.com>

On Fri, Dec 3, 2010 at 4:18 PM, Chris McGraw <cmcgraw at datasyncorp.com> wrote:
> Hello,
> ?I just encountered an issue with easy-install and soaplib (specifically v0.8.1, but I see it's probably affecting all versions). ?It appears the project has been renamed on github, and consequently the URL's for downloading have changed. The url that was http://github.com/downloads/arskom/soaplib/soaplib-0.8.1.tar should now be https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar.

Thanks for pointing out this is broken; I'll fix it shortly.

We are transitioning soaplib to a new "organization" on GitHub, so the
PyPI download link should not go to rpclib repo. There is now a
separate rpclib entry in PyPI:

https://github.com/soaplib/soaplib



, there is a separate PyPI entry for rpclib


From bradallen137 at gmail.com  Mon Dec  6 18:27:26 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Mon, 6 Dec 2010 11:27:26 -0600
Subject: [Soap-Python] Soaplib on pypi
In-Reply-To: <AANLkTimAFj5n=HNwAcVQxZFMOv_FnN5jb0shsxqwmJ3F@mail.gmail.com>
References: <1320141028.52534.1291414700423.JavaMail.root@mailbox1>
	<2088279944.52536.1291414708455.JavaMail.root@mailbox1>
	<AANLkTimAFj5n=HNwAcVQxZFMOv_FnN5jb0shsxqwmJ3F@mail.gmail.com>
Message-ID: <AANLkTim8QxVznmtgMeNUc8hBtEepCuJrGWZFzg_vDPBL@mail.gmail.com>

On Sat, Dec 4, 2010 at 8:50 AM, Brad Allen <bradallen137 at gmail.com> wrote:
> On Fri, Dec 3, 2010 at 4:18 PM, Chris McGraw <cmcgraw at datasyncorp.com> wrote:
>> Hello,
>> ?I just encountered an issue with easy-install and soaplib (specifically v0.8.1, but I see it's probably affecting all versions). ?It appears the project has been renamed on github, and consequently the URL's for downloading have changed. The url that was http://github.com/downloads/arskom/soaplib/soaplib-0.8.1.tar should now be https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar.

Sorry for the delay in fixing this.

Oddly, 0.8.1 doesn't appear to be tagged in arksom/rpclib so when
soaplib/soaplib was forked, the tag was not present.

I did find the soaplib-0.8.1.tar file in the
https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar but I
wish I could find the tag it's based on. This must have something to
do with the fragmented history of soaplib, when there were several
unconnected GitHub repos.

Anyway, that  0.8.1 version is now uploaded to PyPI. I didn't see the
issue with any of the other versions I checked; when I spot checked a
few they all had files uploaded to PyPI.


From tseaver at palladion.com  Mon Dec  6 19:21:17 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 06 Dec 2010 13:21:17 -0500
Subject: [Soap-Python] Soaplib on pypi
In-Reply-To: <AANLkTim8QxVznmtgMeNUc8hBtEepCuJrGWZFzg_vDPBL@mail.gmail.com>
References: <1320141028.52534.1291414700423.JavaMail.root@mailbox1>	<2088279944.52536.1291414708455.JavaMail.root@mailbox1>	<AANLkTimAFj5n=HNwAcVQxZFMOv_FnN5jb0shsxqwmJ3F@mail.gmail.com>
	<AANLkTim8QxVznmtgMeNUc8hBtEepCuJrGWZFzg_vDPBL@mail.gmail.com>
Message-ID: <idj9iq$o2f$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/06/2010 12:27 PM, Brad Allen wrote:
> On Sat, Dec 4, 2010 at 8:50 AM, Brad Allen <bradallen137 at gmail.com> wrote:
>> On Fri, Dec 3, 2010 at 4:18 PM, Chris McGraw <cmcgraw at datasyncorp.com> wrote:
>>> Hello,
>>>  I just encountered an issue with easy-install and soaplib (specifically v0.8.1, but I see it's probably affecting all versions).  It appears the project has been renamed on github, and consequently the URL's for downloading have changed. The url that was http://github.com/downloads/arskom/soaplib/soaplib-0.8.1.tar should now be https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar.
> 
> Sorry for the delay in fixing this.
> 
> Oddly, 0.8.1 doesn't appear to be tagged in arksom/rpclib so when
> soaplib/soaplib was forked, the tag was not present.
> 
> I did find the soaplib-0.8.1.tar file in the
> https://github.com/downloads/arskom/rpclib/soaplib-0.8.1.tar but I
> wish I could find the tag it's based on. This must have something to
> do with the fragmented history of soaplib, when there were several
> unconnected GitHub repos.
> 
> Anyway, that  0.8.1 version is now uploaded to PyPI. I didn't see the
> issue with any of the other versions I checked; when I spot checked a
> few they all had files uploaded to PyPI.

I found that commit 8dcfc5228a361b9a77b3e68c6b82e5e0e7f9829c bumped the
version to '0.8.1' on 2010-07-14, via:

  $ git log soaplib-0_9 -p setup.py



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz9KZ0ACgkQ+gerLs4ltQ4uugCffxkp1Q5igsBRMCTe3Va4hmxK
46gAoIbmWrZpx4ZgKDPrRAS+A1E9bEPL
=qUa2
-----END PGP SIGNATURE-----



From tseaver at palladion.com  Thu Dec  9 17:48:53 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 09 Dec 2010 11:48:53 -0500
Subject: [Soap-Python] Pulling my branch
Message-ID: <idr19l$dhu$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not seeing any review for my earlier pull request[1], which allowed
messages containing header XML to be dispatched to service methods which
didn't define an input header class.

I have just pushed a couple more changes, which allow running all the
"unit" tests (those outside the 'interop' sub-package) easily via:

 $ python setup.py test

Any objection if I merge all three?


[1]https://github.com/tseaver/soaplib/commit/63cf483165a1fde34905c119fd1091251d5eb829
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0BCHUACgkQ+gerLs4ltQ4mvwCffWnLRFX7883rbmIgTLoFw8UH
JxIAnRfvv/l2bDA7Hm0LX+rCTpTwYXCM
=tf2u
-----END PGP SIGNATURE-----



From bradallen137 at gmail.com  Thu Dec  9 18:18:42 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 9 Dec 2010 11:18:42 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <idr19l$dhu$1@dough.gmane.org>
References: <idr19l$dhu$1@dough.gmane.org>
Message-ID: <AANLkTikL26S5P+5cNAnvifbu3G6ZHd4ZOO2Buixmhn4i@mail.gmail.com>

Chris didn't get an email notifying him of the pull request, even
though it appears on the soaplib/soaplib news feed. He'll review it
today...please hold off from merging for now.

On Thu, Dec 9, 2010 at 10:48 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm not seeing any review for my earlier pull request[1], which allowed
> messages containing header XML to be dispatched to service methods which
> didn't define an input header class.
>
> I have just pushed a couple more changes, which allow running all the
> "unit" tests (those outside the 'interop' sub-package) easily via:
>
> ?$ python setup.py test
>
> Any objection if I merge all three?
>
>
> [1]https://github.com/tseaver/soaplib/commit/63cf483165a1fde34905c119fd1091251d5eb829
> - --
> ===================================================================
> Tres Seaver ? ? ? ? ?+1 540-429-0999 ? ? ? ? ?tseaver at palladion.com
> Palladion Software ? "Excellence by Design" ? ?http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0BCHUACgkQ+gerLs4ltQ4mvwCffWnLRFX7883rbmIgTLoFw8UH
> JxIAnRfvv/l2bDA7Hm0LX+rCTpTwYXCM
> =tf2u
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From chris at sydneysys.com  Thu Dec  9 18:18:45 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 9 Dec 2010 11:18:45 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <idr19l$dhu$1@dough.gmane.org>
References: <idr19l$dhu$1@dough.gmane.org>
Message-ID: <AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>

Hey Trey,

For some reason I didn't get an email for the pull request.  Give me a
little bit and I'll take a look at it.

Thanks

On Thu, Dec 9, 2010 at 10:48 AM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm not seeing any review for my earlier pull request[1], which allowed
> messages containing header XML to be dispatched to service methods which
> didn't define an input header class.
>
> I have just pushed a couple more changes, which allow running all the
> "unit" tests (those outside the 'interop' sub-package) easily via:
>
>  $ python setup.py test
>
> Any objection if I merge all three?
>
>
> [1]
> https://github.com/tseaver/soaplib/commit/63cf483165a1fde34905c119fd1091251d5eb829
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0BCHUACgkQ+gerLs4ltQ4mvwCffWnLRFX7883rbmIgTLoFw8UH
> JxIAnRfvv/l2bDA7Hm0LX+rCTpTwYXCM
> =tf2u
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101209/aa0c84ef/attachment.html>

From tseaver at palladion.com  Thu Dec  9 21:14:15 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 09 Dec 2010 15:14:15 -0500
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
Message-ID: <idrdan$ef3$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2010 12:18 PM, Chris Austin wrote:

> For some reason I didn't get an email for the pull request.  Give me a
> little bit and I'll take a look at it.

Thanks for merging it!  I've got more changes coming, some of which need
some discussion:

1. I want method descriptors to keep the list of faults passed to the
   'rpc' decorator.  I have this one working already.

2. I want to emit the WSDL for faults of operations:  types, messages,
   and parts.  I'm part way hacking through this.  AFAICT, application-
   defined faults are effectively unused:  for instance, calling
   'fault.add_to_schema(schema_entries)' blows up because the emitted
   WSDL is broken.  Can anyone contradict me, here?  I.e., is anyone
   using application-defined faults at all?

3. I want some way to suppress the wrapping of returned objects in
   sequences (see issue 4,
   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
   of maybe spelling that as a '_returns_direct' argument to 'rpc()'.

   For my enlightenment:  does anybody know the rationale for adding the
   sequence wrapper?



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0BOJcACgkQ+gerLs4ltQ7dRwCghFeR3QxWHU0Q37bzzuPd7kao
PBsAn2UEl204jYfghXHEmfM4z5LTxHK5
=YuNZ
-----END PGP SIGNATURE-----



From chris at sydneysys.com  Thu Dec  9 21:48:26 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 9 Dec 2010 14:48:26 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <idrdan$ef3$1@dough.gmane.org>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
Message-ID: <AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>

On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2010 12:18 PM, Chris Austin wrote:
>
> > For some reason I didn't get an email for the pull request.  Give me a
> > little bit and I'll take a look at it.
>
> Thanks for merging it!  I've got more changes coming, some of which need
> some discussion:
>
> 1. I want method descriptors to keep the list of faults passed to the
>   'rpc' decorator.  I have this one working already.
>
>
This would be fine with me.  While we are at it, is everybody fine with
dropping the single underscore from the decorator for items like _returns?

I am asking because I am in the mist of a huge overhaul for the wsdl engine
along with some supporting changes to the rpc decorator.



> 2. I want to emit the WSDL for faults of operations:  types, messages,
>   and parts.  I'm part way hacking through this.  AFAICT, application-
>   defined faults are effectively unused:  for instance, calling
>   'fault.add_to_schema(schema_entries)' blows up because the emitted
>   WSDL is broken.  Can anyone contradict me, here?  I.e., is anyone
>   using application-defined faults at all?


 This sounds right with the new tests I have been writing around the wsdl
engine.  There are lots of other little issues like it  currently stuffing
all of the services into a single service named after the App .


> 3. I want some way to suppress the wrapping of returned objects in
>   sequences (see issue 4,
>   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
>   of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
>
>   For my enlightenment:  does anybody know the rationale for adding the
>   sequence wrapper?
>

I can't comment on the historical decisions however; I just don't know but I
can make up stuff if needed :)

This  sounds fine with me.  Let's think about dropping the underscore on
the parameter however.  Does anybody have an objection for altering the
syntax in the rpc decorator slightly

currently -> @rpc(String, Integer, Double, ..., _returns=String)
proposed -> @rpc(String, Integer, Double, ..., _returns=String)


Also, I'd like to modify the way the instances of ClassSerializer declare
class attributes by dropping the double underscore.

for example currently things look like this:

class MyModel(ClassSerializer):
    __namespace__ = 'foo'

I'd like to make it cleaner like so:

class MyModel(ClassSerializer):
    namespace = 'foo'


Also, to properly support ports and separate services I am
currently finishing tests for adding  'ports' and 'service_interface'
attributes to DefinitionBase along with a 'port' attribute for the
'rpc' decorator.

If no one objects I'll drop the (in my opinion) superfluous underscores.

Cheers



>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0BOJcACgkQ+gerLs4ltQ7dRwCghFeR3QxWHU0Q37bzzuPd7kao
> PBsAn2UEl204jYfghXHEmfM4z5LTxHK5
> =YuNZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101209/e41de3d3/attachment.html>

From chris at sydneysys.com  Thu Dec  9 21:55:59 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 9 Dec 2010 14:55:59 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
Message-ID: <AANLkTiktYvu_bntsT45g6KqHRAsUnjd47tDTddLGewtN@mail.gmail.com>

>
> This  sounds fine with me.  Let's think about dropping the underscore on
> the parameter however.  Does anybody have an objection for altering the
> syntax in the rpc decorator slightly
>
> currently -> @rpc(String, Integer, Double, ..., _returns=String)
> proposed -> @rpc(String, Integer, Double, ..., _returns=String)
>
>
Sorry everyone; I meant to type:

proposed -> @rpc(String, Integer, Double, ..., returns=String)

looks like I've typed too many of these and my fingers are just too used to
doing it this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101209/f4cfe02c/attachment.html>

From bradallen137 at gmail.com  Thu Dec  9 22:05:01 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 9 Dec 2010 15:05:01 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
Message-ID: <AANLkTi=9kKdz_Qi_RC7RDz6SeQbcXx1Xd0n+vu=_7jUQ@mail.gmail.com>

Folks, this is the time for changes that break backward compatibility.
Since we have not yet released 2.0 beta, there is still time to get in
those kinds of changes. After the 2.0 beta release, changes that break
backward compatibility should be deferred to the next major release
(3.0).

I'm all in favor of getting rid of the unnecessary underscores in
parameter names; those are supposed to be used for private methods, so
I don't see how they make sense for keyword parameters. Maybe someone
with greater historical perspective could chime in an explain the
thinking?

Also, for the __attributes__, those are generally reserved for Python
itself, right? A lot of framework developers use them but I don't
think it's a good idea, and not in keeping with PEP 8.

>From PEP 8, the Python Style Guide at http://www.python.org/dev/peps/pep-0008/

- __double_leading_and_trailing_underscore__: "magic" objects or
      attributes that live in user-controlled namespaces.  E.g. __init__,
      __import__ or __file__.  Never invent such names; only use them
      as documented.

On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com> wrote:
> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/09/2010 12:18 PM, Chris Austin wrote:
>>
>> > For some reason I didn't get an email for the pull request. ?Give me a
>> > little bit and I'll take a look at it.
>>
>> Thanks for merging it! ?I've got more changes coming, some of which need
>> some discussion:
>>
>> 1. I want method descriptors to keep the list of faults passed to the
>> ? 'rpc' decorator. ?I have this one working already.
>>
>
> This would be fine with me. ?While we are at it, is everybody fine with
> dropping the single underscore from the decorator for items like _returns?
> I am asking because I am in the mist of a huge overhaul for the wsdl engine
> along with some supporting changes to the rpc decorator.
>
>>
>> 2. I want to emit the WSDL for faults of operations: ?types, messages,
>> ? and parts. ?I'm part way hacking through this. ?AFAICT, application-
>> ? defined faults are effectively unused: ?for instance, calling
>> ? 'fault.add_to_schema(schema_entries)' blows up because the emitted
>> ? WSDL is broken. ?Can anyone contradict me, here? ?I.e., is anyone
>> ? using application-defined faults at all?
>
> ?This sounds right with the new tests I have been writing around the wsdl
> engine. ?There are lots of other little issues like it ?currently stuffing
> all of the services into a single service named after the App .
>
>>
>> 3. I want some way to suppress the wrapping of returned objects in
>> ? sequences (see issue 4,
>> ? https://github.com/soaplib/soaplib/issues#issue/4). ?I'm thinking
>> ? of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
>>
>> ? For my enlightenment: ?does anybody know the rationale for adding the
>> ? sequence wrapper?
>
> I can't comment on the historical decisions however; I just don't know but I
> can make up stuff if needed :)
> This ?sounds fine with me. ?Let's think about dropping the underscore on
> the?parameter?however. ?Does anybody have an objection for altering the
> syntax in the rpc decorator slightly
> currently -> @rpc(String, Integer, Double, ..., _returns=String)
> proposed -> @rpc(String, Integer, Double, ..., _returns=String)
>
> Also, I'd like to modify the way the instances of ClassSerializer declare
> class attributes by dropping the double underscore.
> for example currently things look like this:
> class MyModel(ClassSerializer):
> ?? ?__namespace__ = 'foo'
> I'd like to make it cleaner like so:
> class MyModel(ClassSerializer):
> ?? ?namespace = 'foo'
>
> Also, to properly support ports and?separate?services I am
> currently?finishing?tests for adding ?'ports' and 'service_interface'
> attributes to DefinitionBase along with a 'port' attribute for the
> 'rpc'?decorator.
> If no one objects I'll drop the (in my opinion)?superfluous?underscores.
> Cheers
>
>
>>
>> Tres.
>> - --
>> ===================================================================
>> Tres Seaver ? ? ? ? ?+1 540-429-0999 ? ? ? ? ?tseaver at palladion.com
>> Palladion Software ? "Excellence by Design" ? ?http://palladion.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk0BOJcACgkQ+gerLs4ltQ7dRwCghFeR3QxWHU0Q37bzzuPd7kao
>> PBsAn2UEl204jYfghXHEmfM4z5LTxHK5
>> =YuNZ
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Soap mailing list
>> Soap at python.org
>> http://mail.python.org/mailman/listinfo/soap
>
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
>


From burak.arslan at arskom.com.tr  Thu Dec  9 22:50:59 2010
From: burak.arslan at arskom.com.tr (burak.arslan at arskom.com.tr)
Date: Thu, 09 Dec 2010 23:50:59 +0200
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTi=9kKdz_Qi_RC7RDz6SeQbcXx1Xd0n+vu=_7jUQ@mail.gmail.com>
References: "<idr19l$dhu$1@dough.gmane.org>	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>	<idrdan$ef3$1@dough.gmane.org>"
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
	<AANLkTi=9kKdz_Qi_RC7RDz6SeQbcXx1Xd0n+vu=_7jUQ@mail.gmail.com>
Message-ID: <93b06b0c4ab8eaf2407c59b7bce52354@arskom.com.tr>

 On Thu, 9 Dec 2010 15:05:01 -0600, Brad Allen <bradallen137 at gmail.com> 
 wrote:
> Folks, this is the time for changes that break backward 
> compatibility.
> Since we have not yet released 2.0 beta, there is still time to get 
> in
> those kinds of changes. After the 2.0 beta release, changes that 
> break
> backward compatibility should be deferred to the next major release
> (3.0).
>
> I'm all in favor of getting rid of the unnecessary underscores in
> parameter names; those are supposed to be used for private methods, 
> so
> I don't see how they make sense for keyword parameters. Maybe someone
> with greater historical perspective could chime in an explain the
> thinking?
>

 _returns and its ilk have an underscore because they are considered to 
 be keywords with special meanings. i think the plan was to have

 @rpc(some_param=String, some_other=Double, _returns=SomeClass)
 def my_function(**kwargs):

 in an effort to avoid duplication in definitions. you can still do it, 
 i think it looks nice.

 burak



> Also, for the __attributes__, those are generally reserved for Python
> itself, right? A lot of framework developers use them but I don't
> think it's a good idea, and not in keeping with PEP 8.
>
>>From PEP 8, the Python Style Guide at 
>> http://www.python.org/dev/peps/pep-0008/
>
> - __double_leading_and_trailing_underscore__: "magic" objects or
>       attributes that live in user-controlled namespaces.  E.g. 
> __init__,
>       __import__ or __file__.  Never invent such names; only use them
>       as documented.
>
> On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com> 
> wrote:
>> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> 
>> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/09/2010 12:18 PM, Chris Austin wrote:
>>>
>>> > For some reason I didn't get an email for the pull request. ?Give 
>>> me a
>>> > little bit and I'll take a look at it.
>>>
>>> Thanks for merging it! ?I've got more changes coming, some of which 
>>> need
>>> some discussion:
>>>
>>> 1. I want method descriptors to keep the list of faults passed to 
>>> the
>>> ? 'rpc' decorator. ?I have this one working already.
>>>
>>
>> This would be fine with me. ?While we are at it, is everybody fine 
>> with
>> dropping the single underscore from the decorator for items like 
>> _returns?
>> I am asking because I am in the mist of a huge overhaul for the wsdl 
>> engine
>> along with some supporting changes to the rpc decorator.
>>
>>>
>>> 2. I want to emit the WSDL for faults of operations: ?types, 
>>> messages,
>>> ? and parts. ?I'm part way hacking through this. ?AFAICT, 
>>> application-
>>> ? defined faults are effectively unused: ?for instance, calling
>>> ? 'fault.add_to_schema(schema_entries)' blows up because the 
>>> emitted
>>> ? WSDL is broken. ?Can anyone contradict me, here? ?I.e., is anyone
>>> ? using application-defined faults at all?
>>
>> ?This sounds right with the new tests I have been writing around the 
>> wsdl
>> engine. ?There are lots of other little issues like it ?currently 
>> stuffing
>> all of the services into a single service named after the App .
>>
>>>
>>> 3. I want some way to suppress the wrapping of returned objects in
>>> ? sequences (see issue 4,
>>> ? https://github.com/soaplib/soaplib/issues#issue/4). ?I'm thinking
>>> ? of maybe spelling that as a '_returns_direct' argument to 
>>> 'rpc()'.
>>>
>>> ? For my enlightenment: ?does anybody know the rationale for adding 
>>> the
>>> ? sequence wrapper?
>>
>> I can't comment on the historical decisions however; I just don't 
>> know but I
>> can make up stuff if needed :)
>> This ?sounds fine with me. ?Let's think about dropping the 
>> underscore on
>> the?parameter?however. ?Does anybody have an objection for altering 
>> the
>> syntax in the rpc decorator slightly
>> currently -> @rpc(String, Integer, Double, ..., _returns=String)
>> proposed -> @rpc(String, Integer, Double, ..., _returns=String)
>>
>> Also, I'd like to modify the way the instances of ClassSerializer 
>> declare
>> class attributes by dropping the double underscore.
>> for example currently things look like this:
>> class MyModel(ClassSerializer):
>> ?? ?__namespace__ = 'foo'
>> I'd like to make it cleaner like so:
>> class MyModel(ClassSerializer):
>> ?? ?namespace = 'foo'
>>
>> Also, to properly support ports and?separate?services I am
>> currently?finishing?tests for adding ?'ports' and 
>> 'service_interface'
>> attributes to DefinitionBase along with a 'port' attribute for the
>> 'rpc'?decorator.
>> If no one objects I'll drop the (in my 
>> opinion)?superfluous?underscores.
>> Cheers
>>
>>
>>>
>>> Tres.
>>> - --
>>> ===================================================================
>>> Tres Seaver ? ? ? ? ?+1 540-429-0999 ? ? ? ? ?tseaver at palladion.com
>>> Palladion Software ? "Excellence by Design" ? ?http://palladion.com
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk0BOJcACgkQ+gerLs4ltQ7dRwCghFeR3QxWHU0Q37bzzuPd7kao
>>> PBsAn2UEl204jYfghXHEmfM4z5LTxHK5
>>> =YuNZ
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Soap mailing list
>>> Soap at python.org
>>> http://mail.python.org/mailman/listinfo/soap
>>
>>
>> _______________________________________________
>> Soap mailing list
>> Soap at python.org
>> http://mail.python.org/mailman/listinfo/soap
>>
>>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap



From bradallen137 at gmail.com  Thu Dec  9 23:14:58 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 9 Dec 2010 16:14:58 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
Message-ID: <AANLkTikkkkYUoC=joy-ekK5hE+LvZfNR2FDHC4gRgsm3@mail.gmail.com>

On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com> wrote:
> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> wrote:
>> 3. I want some way to suppress the wrapping of returned objects in
>> ? sequences (see issue 4,
>> ? https://github.com/soaplib/soaplib/issues#issue/4). ?I'm thinking
>> ? of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
>>
>> ? For my enlightenment: ?does anybody know the rationale for adding the
>> ? sequence wrapper?

Like Chris Austin I have no idea where this came from. Chris checked
the SOAP spec and only one return value is expected...a sequence is
not called for.

Maybe someone was thinking about how Python functions support multiple
return values?

If it's not in the spec I don't see why soaplib should do it at all.
If multiple return values are ever needed then a sequence can always
be specified as the return type, right?


From harsha.mukkera at gmail.com  Thu Dec  9 23:35:34 2010
From: harsha.mukkera at gmail.com (mukkera harsha)
Date: Thu, 9 Dec 2010 16:35:34 -0600
Subject: [Soap-Python] please unsubscribe me
Message-ID: <AANLkTinMbn7a_g8D0QAYKUgY7dVN7Gjq8w3rVFpYAJVZ@mail.gmail.com>

Can you please unsubscribe me from tis mailing list !!!
-- 
Harshavardhan Reddy Mukkera.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101209/6c59f621/attachment.html>

From baiju.m.mail at gmail.com  Fri Dec 10 04:35:08 2010
From: baiju.m.mail at gmail.com (Baiju M)
Date: Fri, 10 Dec 2010 09:05:08 +0530
Subject: [Soap-Python] please unsubscribe me
In-Reply-To: <AANLkTinMbn7a_g8D0QAYKUgY7dVN7Gjq8w3rVFpYAJVZ@mail.gmail.com>
References: <AANLkTinMbn7a_g8D0QAYKUgY7dVN7Gjq8w3rVFpYAJVZ@mail.gmail.com>
Message-ID: <AANLkTik_zbK00UX8SQVn9LEa7BWTXY=AgiFHF_mx7300@mail.gmail.com>

On Fri, Dec 10, 2010 at 4:05 AM, mukkera harsha
<harsha.mukkera at gmail.com> wrote:
>
> Can you please unsubscribe me from tis mailing list !!!

You can do it yourself, loot at the link given at the bottom of the mail.

--
Baiju M


From tseaver at palladion.com  Fri Dec 10 14:20:10 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 10 Dec 2010 08:20:10 -0500
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTikkkkYUoC=joy-ekK5hE+LvZfNR2FDHC4gRgsm3@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>	<idrdan$ef3$1@dough.gmane.org>	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
	<AANLkTikkkkYUoC=joy-ekK5hE+LvZfNR2FDHC4gRgsm3@mail.gmail.com>
Message-ID: <idt9ea$7bk$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2010 05:14 PM, Brad Allen wrote:
> On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com> wrote:
>> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> wrote:
>>> 3. I want some way to suppress the wrapping of returned objects in
>>>   sequences (see issue 4,
>>>   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
>>>   of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
>>>
>>>   For my enlightenment:  does anybody know the rationale for adding the
>>>   sequence wrapper?
> 
> Like Chris Austin I have no idea where this came from. Chris checked
> the SOAP spec and only one return value is expected...a sequence is
> not called for.
> 
> Maybe someone was thinking about how Python functions support multiple
> return values?
> 
> If it's not in the spec I don't see why soaplib should do it at all.
> If multiple return values are ever needed then a sequence can always
> be specified as the return type, right?

Perhaps the sequence wrappers are implemented with the "rpc" operation
style in mind?  See: http://www.w3.org/TR/wsdl#_soap:operation and
http://www.w3.org/TR/wsdl#_soap:body, which then refer
tohttp://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383533, which
says (about the response):

- - A method response is modelled as a struct.

- - The method response is viewed as a single struct containing an
  accessor for the return value and each [out] or [in/out] parameter.
  The first accessor is the return value followed by the parameters in
  the same order as in the method signature.

However, soaplib emits WSDP for bindings and operations as
'style="document"', which doesn't need any of that.

Perhaps I should add a '@document' decorator, which causes the WSDL for
return types to be what I need, and have the '@rpc' decorator cause the
biniding to be marked with 'style="rpc"'?


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0CKQoACgkQ+gerLs4ltQ4cKACeMo+XfkGk+P9WH6Kx79VKnZP2
rk0AoNFTgspA/AYHddKjMYFkQpt/xkpf
=THPo
-----END PGP SIGNATURE-----



From chris at sydneysys.com  Fri Dec 10 16:01:04 2010
From: chris at sydneysys.com (Chris Austin)
Date: Fri, 10 Dec 2010 09:01:04 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <AANLkTinpYgsRJ=MU89ydw1yu1XLeNJxQ_mMknpyXHiuU@mail.gmail.com>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
	<AANLkTikkkkYUoC=joy-ekK5hE+LvZfNR2FDHC4gRgsm3@mail.gmail.com>
	<idt9ea$7bk$1@dough.gmane.org>
	<AANLkTinpYgsRJ=MU89ydw1yu1XLeNJxQ_mMknpyXHiuU@mail.gmail.com>
Message-ID: <AANLkTik_TJS_+CWEq_TvbkAExrCxNRC2O=mrOBLcCNNE@mail.gmail.com>

On Fri, Dec 10, 2010 at 7:20 AM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2010 05:14 PM, Brad Allen wrote:
> > On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com>
> wrote:
> >> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com>
> wrote:
> >>> 3. I want some way to suppress the wrapping of returned objects in
> >>>   sequences (see issue 4,
> >>>   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
> >>>   of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
> >>>
> >>>   For my enlightenment:  does anybody know the rationale for adding the
> >>>   sequence wrapper?
> >
> > Like Chris Austin I have no idea where this came from. Chris checked
> > the SOAP spec and only one return value is expected...a sequence is
> > not called for.
> >
> > Maybe someone was thinking about how Python functions support multiple
> > return values?
> >
> > If it's not in the spec I don't see why soaplib should do it at all.
> > If multiple return values are ever needed then a sequence can always
> > be specified as the return type, right?
>
> Perhaps the sequence wrappers are implemented with the "rpc" operation
> style in mind?  See: http://www.w3.org/TR/wsdl#_soap:operation and
> http://www.w3.org/TR/wsdl#_soap:body, which then refer
> tohttp://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383533, which
> says (about the response):
>
> - - A method response is modelled as a struct.
>
> - - The method response is viewed as a single struct containing an
>  accessor for the return value and each [out] or [in/out] parameter.
>  The first accessor is the return value followed by the parameters in
>  the same order as in the method signature.
>
> However, soaplib emits WSDP for bindings and operations as
> 'style="document"', which doesn't need any of that.
>
> Perhaps I should add a '@document' decorator, which causes the WSDL for
> return types to be what I need, and have the '@rpc' decorator cause the
> biniding to be marked with 'style="rpc"'?
>

Are you proposing decorator chaining or decorator that handles the same work
as the rpc decorator but with different defaults for this case? Also, I am
happy with simply adding  default 'style' attribute and parameter for the
rpc decorator and documentation the possible values and it's uses.

The only worry I have is which approach becomes less manageable and possibly
more complex from the end user's point of view?



>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0CKQoACgkQ+gerLs4ltQ4cKACeMo+XfkGk+P9WH6Kx79VKnZP2
> rk0AoNFTgspA/AYHddKjMYFkQpt/xkpf
> =THPo
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101210/0ffaf03b/attachment.html>

From chris at sydneysys.com  Fri Dec 10 16:06:56 2010
From: chris at sydneysys.com (Chris Austin)
Date: Fri, 10 Dec 2010 09:06:56 -0600
Subject: [Soap-Python] Pulling my branch
In-Reply-To: <idt9ea$7bk$1@dough.gmane.org>
References: <idr19l$dhu$1@dough.gmane.org>
	<AANLkTi=Jgv1XXAZg3PTbJgLevfNVNw9a6HvUbKvOcgJ8@mail.gmail.com>
	<idrdan$ef3$1@dough.gmane.org>
	<AANLkTiknSQWq2iBeRiRYdVp9wpTr4x4J2kH5MbMPPpN3@mail.gmail.com>
	<AANLkTikkkkYUoC=joy-ekK5hE+LvZfNR2FDHC4gRgsm3@mail.gmail.com>
	<idt9ea$7bk$1@dough.gmane.org>
Message-ID: <AANLkTim1g9aKSUf3TMoNpbUKUaf=4jSYBE2whz_EWOUm@mail.gmail.com>

Also Tres,

Do you think that just dropping the sequence from the response will  give
you a working solution to your issue?  If so, I can try and get that done
this afternoon and not hold things up with finishing re-working the wsdl ans
schema code and the 40+ test cases that I've seemed to find along with those
changes :)

Let me know and if you like we can discuss this further off-list.




On Fri, Dec 10, 2010 at 7:20 AM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2010 05:14 PM, Brad Allen wrote:
> > On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com>
> wrote:
> >> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com>
> wrote:
> >>> 3. I want some way to suppress the wrapping of returned objects in
> >>>   sequences (see issue 4,
> >>>   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
> >>>   of maybe spelling that as a '_returns_direct' argument to 'rpc()'.
> >>>
> >>>   For my enlightenment:  does anybody know the rationale for adding the
> >>>   sequence wrapper?
> >
> > Like Chris Austin I have no idea where this came from. Chris checked
> > the SOAP spec and only one return value is expected...a sequence is
> > not called for.
> >
> > Maybe someone was thinking about how Python functions support multiple
> > return values?
> >
> > If it's not in the spec I don't see why soaplib should do it at all.
> > If multiple return values are ever needed then a sequence can always
> > be specified as the return type, right?
>
> Perhaps the sequence wrappers are implemented with the "rpc" operation
> style in mind?  See: http://www.w3.org/TR/wsdl#_soap:operation and
> http://www.w3.org/TR/wsdl#_soap:body, which then refer
> tohttp://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383533, which
> says (about the response):
>
> - - A method response is modelled as a struct.
>
> - - The method response is viewed as a single struct containing an
>  accessor for the return value and each [out] or [in/out] parameter.
>  The first accessor is the return value followed by the parameters in
>  the same order as in the method signature.
>
> However, soaplib emits WSDP for bindings and operations as
> 'style="document"', which doesn't need any of that.
>
> Perhaps I should add a '@document' decorator, which causes the WSDL for
> return types to be what I need, and have the '@rpc' decorator cause the
> biniding to be marked with 'style="rpc"'?
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0CKQoACgkQ+gerLs4ltQ4cKACeMo+XfkGk+P9WH6Kx79VKnZP2
> rk0AoNFTgspA/AYHddKjMYFkQpt/xkpf
> =THPo
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101210/d6f02e59/attachment.html>

From tseaver at palladion.com  Fri Dec 10 17:00:56 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 10 Dec 2010 11:00:56 -0500
Subject: [Soap-Python] New pull request
Message-ID: <4D024EB8.2000502@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris,

I have pushed code to my github fork which emit WSDL for method faults
in all three places (types, portType operations, binding operations),
and to fix the actual soap:BODY XML emission for application-defined
faults as well.

It looked to me as though you still weren't going to be notified
directly via the pull request, so I am CC'ing here.



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0CTrcACgkQ+gerLs4ltQ72NACfZI9Bd+gcxYDl8ycUtmr+eY2I
Jy0AoNoXLVKSuTQC7m/qMIO6L96mEnUt
=58Sq
-----END PGP SIGNATURE-----



From tseaver at palladion.com  Fri Dec 10 18:39:37 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 10 Dec 2010 12:39:37 -0500
Subject: [Soap-Python] (Another) new pull request
In-Reply-To: <4D024EB8.2000502@palladion.com>
References: <4D024EB8.2000502@palladion.com>
Message-ID: <4D0265D9.40403@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for merging my earlier pull request.

I have another commit pushed, which makes the '@document' decorator work
as I need (I think).  As described in the WSDL spec
(http://www.w3.org/TR/wsdl#_soap:body), the output part for a method
decorated by '@document' is a single element, named by default as
'%sResponse' % method, with the same type info as the declared return type.

My implementation uses a separate function for generating the output
message class, making it a dumb alias for the actual return type
declared for the method.

The pull request is here:

 https://github.com/soaplib/soaplib/pull/8


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0CZdkACgkQ+gerLs4ltQ55XwCgtYYPcrGlaAIDJo62JiNEQK3y
SvYAnjLMQX14T79GZYG8e6Qc6gmgbWxY
=WX0X
-----END PGP SIGNATURE-----



From chris at sydneysys.com  Tue Dec 14 23:43:48 2010
From: chris at sydneysys.com (Chris Austin)
Date: Tue, 14 Dec 2010 16:43:48 -0600
Subject: [Soap-Python] Renaming the rpc decorator.
Message-ID: <1292366628.27565.1.camel@dAlembertian>

Sometime in the short and confusing history of soaplib the method
decorator @soapmethod was renamed to @rpc in order to support the
previous maintainers vision of creating a generic rpc library based on
the foundations of soaplib.

Currently, the maintainers are looking to re-focus on SOAP and make
soaplib a flexible and eventually complete soap solution for python.
With this in mind one thing we've discussed changing prior to the beta
release is to re-rename @rpc to @soap. But, before we move forward we'd
like to get feedback from the community.

Please speak up if you have an opinion on the matter.

Chris




From tseaver at palladion.com  Wed Dec 15 00:36:38 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 14 Dec 2010 18:36:38 -0500
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <1292366628.27565.1.camel@dAlembertian>
References: <1292366628.27565.1.camel@dAlembertian>
Message-ID: <ie8v26$rdb$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/2010 05:43 PM, Chris Austin wrote:
> Sometime in the short and confusing history of soaplib the method
> decorator @soapmethod was renamed to @rpc in order to support the
> previous maintainers vision of creating a generic rpc library based on
> the foundations of soaplib.
> 
> Currently, the maintainers are looking to re-focus on SOAP and make
> soaplib a flexible and eventually complete soap solution for python.
> With this in mind one thing we've discussed changing prior to the beta
> release is to re-rename @rpc to @soap. But, before we move forward we'd
> like to get feedback from the community.
> 
> Please speak up if you have an opinion on the matter.

At the moment, the '@rpc' decorator is twinned by the '@document'
decorator I added the other day:  each implements one of the "style"
options of the same name for SOAP method result marshalling.

If you mean to rename '@rpc' -> '@soap', then it likely needs to absorb
the functionality currently in '@document' as well, perhaps through an
additional '_style' parameter.

I think I would leave the two as they stand, myself.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0H/4YACgkQ+gerLs4ltQ7dGwCgnnkIDKkdEAKRQWRfpJltUDCx
m5AAoKVX1gnVsNRNazE1KqIrgoXgBrVH
=g46V
-----END PGP SIGNATURE-----



From bradallen137 at gmail.com  Wed Dec 15 04:26:33 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Tue, 14 Dec 2010 21:26:33 -0600
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <ie8v26$rdb$1@dough.gmane.org>
References: <1292366628.27565.1.camel@dAlembertian>
	<ie8v26$rdb$1@dough.gmane.org>
Message-ID: <AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>

On Tue, Dec 14, 2010 at 5:36 PM, Tres Seaver <tseaver at palladion.com> wrote:
> At the moment, the '@rpc' decorator is twinned by the '@document'
> decorator I added the other day: ?each implements one of the "style"
> options of the same name for SOAP method result marshalling.
>
> If you mean to rename '@rpc' -> '@soap', then it likely needs to absorb
> the functionality currently in '@document' as well, perhaps through an
> additional '_style' parameter.
>
> I think I would leave the two as they stand, myself.

A decorator called "document" is just too generic, non-obvious to
anyone who might not understand about the different encoding styles. A
"style" keyword parameter to a "soap" decorator seems a lot more clear
to me.


From luca.dariz at unife.it  Wed Dec 15 08:19:24 2010
From: luca.dariz at unife.it (Luca Dariz)
Date: Wed, 15 Dec 2010 08:19:24 +0100
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>
References: <1292366628.27565.1.camel@dAlembertian>	<ie8v26$rdb$1@dough.gmane.org>
	<AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>
Message-ID: <4D086BFC.5080608@unife.it>

On 15/12/2010 04:26, Brad Allen wrote:
> A decorator called "document" is just too generic, non-obvious to
> anyone who might not understand about the different encoding styles. A
> "style" keyword parameter to a "soap" decorator seems a lot more clear
> to me.
I personally agree with having a "style" parameter. I'll also keep "rpc" 
as the default style.

Luca Dariz


From bradallen137 at gmail.com  Wed Dec 15 17:49:23 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Wed, 15 Dec 2010 10:49:23 -0600
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <4D086BFC.5080608@unife.it>
References: <1292366628.27565.1.camel@dAlembertian>
	<ie8v26$rdb$1@dough.gmane.org>
	<AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>
	<4D086BFC.5080608@unife.it>
Message-ID: <AANLkTikqr2qhumzFaUyEwbU0oDL0oYMOj1DFC+SiAopV@mail.gmail.com>

On Wed, Dec 15, 2010 at 1:19 AM, Luca Dariz <luca.dariz at unife.it> wrote:
> On 15/12/2010 04:26, Brad Allen wrote:
>>
>> A decorator called "document" is just too generic, non-obvious to
>> anyone who might not understand about the different encoding styles. A
>> "style" keyword parameter to a "soap" decorator seems a lot more clear
>> to me.
>
> I personally agree with having a "style" parameter. I'll also keep "rpc" as
> the default style.

Yes, since rpc encoded style was previously the default for we should
keep it that way. If no "style" keyword param is provided, the soap
decorator should default to rpc encoded.

We'll have some soaplib package level constants for this, and should
think about the right names. How about soaplib.RPC_ENCODED and
soaplib.DOC_LITERAL? Chris tells me that supporting
soaplib.RPC_LITERAL and soaplib.DOC_ENCODED are rarely used and
probably not worth the effort of supporting, so we probably won't add
those constants.


From tseaver at palladion.com  Wed Dec 15 21:01:31 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 15 Dec 2010 15:01:31 -0500
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <AANLkTikqr2qhumzFaUyEwbU0oDL0oYMOj1DFC+SiAopV@mail.gmail.com>
References: <1292366628.27565.1.camel@dAlembertian>	<ie8v26$rdb$1@dough.gmane.org>	<AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>	<4D086BFC.5080608@unife.it>
	<AANLkTikqr2qhumzFaUyEwbU0oDL0oYMOj1DFC+SiAopV@mail.gmail.com>
Message-ID: <ieb6qr$uc7$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/15/2010 11:49 AM, Brad Allen wrote:
> On Wed, Dec 15, 2010 at 1:19 AM, Luca Dariz <luca.dariz at unife.it> wrote:
>> On 15/12/2010 04:26, Brad Allen wrote:
>>>
>>> A decorator called "document" is just too generic, non-obvious to
>>> anyone who might not understand about the different encoding styles. A
>>> "style" keyword parameter to a "soap" decorator seems a lot more clear
>>> to me.
>>
>> I personally agree with having a "style" parameter. I'll also keep "rpc" as
>> the default style.
> 
> Yes, since rpc encoded style was previously the default for we should
> keep it that way. If no "style" keyword param is provided, the soap
> decorator should default to rpc encoded.
> 
> We'll have some soaplib package level constants for this, and should
> think about the right names. How about soaplib.RPC_ENCODED and
> soaplib.DOC_LITERAL? Chris tells me that supporting
> soaplib.RPC_LITERAL and soaplib.DOC_ENCODED are rarely used and
> probably not worth the effort of supporting, so we probably won't add
> those constants.

Per the WSDL spec[1], "literal" and "encoded" are orthagonal to the
"style" bit for the method signature.  Assuming we want to let folks
change it I would give them their own argument, maybe '_soap_use' or '_use'?

Note that nothing in soaplib actually supports 'use="encoded"' at all,
AFAICT:  the trunk hard-wires 'use="literal"' everywhere.  I don't
understand the semantics of 'use="encoded"' well enough to even guess at
the effort of implementing that feature.



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0JHpsACgkQ+gerLs4ltQ4PKQCguvOmpCEUvnIxxs/jtu/7dKhf
/MAAnRESWqcuAiKVyF8Q+eQegjj378P2
=o7ty
-----END PGP SIGNATURE-----



From chris at sydneysys.com  Wed Dec 15 22:48:31 2010
From: chris at sydneysys.com (Chris Austin)
Date: Wed, 15 Dec 2010 15:48:31 -0600
Subject: [Soap-Python] Renaming the rpc decorator.
In-Reply-To: <ieb6qr$uc7$1@dough.gmane.org>
References: <1292366628.27565.1.camel@dAlembertian>
	<ie8v26$rdb$1@dough.gmane.org>
	<AANLkTi=mGj_aDTxoacAU5wJPzV09DrEgXW9DnNwBg5m_@mail.gmail.com>
	<4D086BFC.5080608@unife.it>
	<AANLkTikqr2qhumzFaUyEwbU0oDL0oYMOj1DFC+SiAopV@mail.gmail.com>
	<ieb6qr$uc7$1@dough.gmane.org>
Message-ID: <1292449711.6550.24.camel@dAlembertian>



On Wed, 2010-12-15 at 15:01 -0500, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/15/2010 11:49 AM, Brad Allen wrote:
> > On Wed, Dec 15, 2010 at 1:19 AM, Luca Dariz <luca.dariz at unife.it> wrote:
> >> On 15/12/2010 04:26, Brad Allen wrote:
> >>>
> >>> A decorator called "document" is just too generic, non-obvious to
> >>> anyone who might not understand about the different encoding styles. A
> >>> "style" keyword parameter to a "soap" decorator seems a lot more clear
> >>> to me.
> >>
> >> I personally agree with having a "style" parameter. I'll also keep "rpc" as
> >> the default style.
> > 
> > Yes, since rpc encoded style was previously the default for we should
> > keep it that way. If no "style" keyword param is provided, the soap
> > decorator should default to rpc encoded.
> > 
> > We'll have some soaplib package level constants for this, and should
> > think about the right names. How about soaplib.RPC_ENCODED and
> > soaplib.DOC_LITERAL? Chris tells me that supporting
> > soaplib.RPC_LITERAL and soaplib.DOC_ENCODED are rarely used and
> > probably not worth the effort of supporting, so we probably won't add
> > those constants.
> 
> Per the WSDL spec[1], "literal" and "encoded" are orthagonal to the
> "style" bit for the method signature.  Assuming we want to let folks
> change it I would give them their own argument, maybe '_soap_use' or '_use'?
> 
> Note that nothing in soaplib actually supports 'use="encoded"' at all,
> AFAICT:  the trunk hard-wires 'use="literal"' everywhere.  I don't
> understand the semantics of 'use="encoded"' well enough to even guess at
> the effort of implementing that feature.
> 

Initially we can use just use style constants soaplib.RPC_STYLE and
soaplib.DOC_STYLE.  How does that sound.

Strictly speaking we can have the following four style/use secinarios:

1) RPC/encoded
2) RPC/literal
3) Doc/encoded 
4) Doc/literal

and supposedly there is a non-soap specified style/use refereed to as
doc/literal-wrapped that is advocated by some people at IBM.

The problem with using rpc/encoded and doc/encoded is that while they
are valid WSDL they are not WSI-compliant.  

I'd like to provide a consistent model and try to be compliant with as
many consumers/clients as possible.  So, should we attempt to provide
support for the encoded spec?  Or would it be better to continue to
hard-code our use='' to literal and make sure that messages our server
generates are consistent.

> 
> 
> Tres.
> - -- 
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk0JHpsACgkQ+gerLs4ltQ4PKQCguvOmpCEUvnIxxs/jtu/7dKhf
> /MAAnRESWqcuAiKVyF8Q+eQegjj378P2
> =o7ty
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap



From bradallen137 at gmail.com  Thu Dec 16 22:59:37 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 16 Dec 2010 15:59:37 -0600
Subject: [Soap-Python] spinning off soaplib.client, and other pieces
Message-ID: <AANLkTimAmbjDPJYmYonvezs2rqLHbB9_eN325-GZg+M1@mail.gmail.com>

Chris Austin and I were discussing the upcoming beta 2.0 release, and
are thinking seriously about separating out the code for the soaplib
client. Supporting the soaplib client is not a priority for us given
that suds works well, and the client tests are failing. We don't want
to produce a release which includes failing tests.

We can treat soaplib as a namespace package, as long as the existing
soaplib's top level __init__.py does not contain any code. That would
open the door to other soaplib.* packages, giving us the following
family:

soaplib  -- the main package which still includes the server,
services, models, etc. Top level namespace entities need to be
relocated.
soaplib.client -- the lxml-based alternative to suds (still experimental)
soaplib.zope -- support for Zope and accompanying tests
soaplib.0mq  -- support for 0mq  and accompanying tests

Each of these will be a separate repo under the soaplib organization
in GitHub. Only soaplib and soaplib.zope will be maintained with PyPI
releases, unless someone else volunteers to handle releases for
soaplib.client and soaplib.0mq. I'll grant the necessary GitHub access
to any such volunteers.

Any opinions/thoughts?


From reingart at gmail.com  Tue Dec 21 00:44:18 2010
From: reingart at gmail.com (Mariano Reingart)
Date: Mon, 20 Dec 2010 20:44:18 -0300
Subject: [Soap-Python] PySimpleSoap 1.02c released
Message-ID: <AANLkTi=bk0uHLAJxLcDBEk_XPG5XA+-ATj-O5_KtrFmN@mail.gmail.com>

Just released a new revision (1.02c "beta3") of PySimpleSOAP, a
webservice python library:

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

This release includes stabilized code now used in production in
related projects, with more than 18 commits in the last three months
and a couple of major issues fixed.

Changelog:
 * WSDL support overhauled (schema imports, complexContent, extension)
and local file caching
 * Resolved more compatibility issues with axis2 and .net
 * Some marshaling adjustments, parameter sort order, etc.
 * Minor bugs fixed and code cleanup

Download:
http://pysimplesoap.googlecode.com/files/pysimplesoap-1.02c.zip

Please test and comment on the project site or using this
soap at python.org list, specially if you have filled an issue, please
re-check it, so version 1.03 "stable" could be released in the short
term.

If anyone want to contribute as project member, just let me know.

Best regards,

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


From chris at sydneysys.com  Tue Dec 21 20:09:08 2010
From: chris at sydneysys.com (Chris Austin)
Date: Tue, 21 Dec 2010 13:09:08 -0600
Subject: [Soap-Python] soaplib recipies
Message-ID: <1292958548.2574.11.camel@dAlembertian>

Hi folks,

The beta release for 2.0 is near and I'm looking to put a halt to
redesign/new features and start cleaning up the documentation.  So, is
anybody using soaplib inside or parallel to another framework such as
turbogears, django and, cherry-py?  If so, would you mind sharing your
general approach so that we can add it to our documentation as a
recipe/example?  

Cheers

Chris



From jspies at sun.ac.za  Wed Dec 22 07:34:10 2010
From: jspies at sun.ac.za (Johann Spies)
Date: Wed, 22 Dec 2010 08:34:10 +0200
Subject: [Soap-Python] soaplib recipies
In-Reply-To: <1292958548.2574.11.camel@dAlembertian>
References: <1292958548.2574.11.camel@dAlembertian>
Message-ID: <20101222063410.GA1866@sun.ac.za>

On Tue, Dec 21, 2010 at 09:09:08PM +0200, Chris Austin wrote:

> The beta release for 2.0 is near and I'm looking to put a halt to
> redesign/new features and start cleaning up the documentation.  So, is
> anybody using soaplib inside or parallel to another framework such as
> turbogears, django and, cherry-py?  If so, would you mind sharing your
> general approach so that we can add it to our documentation as a
> recipe/example?  

I am too much of a soap newbie to send examples.  I am using web2py.

There are simple examples of using soap(pysimplesoap) in web2py in the
web2py-book
(http://www.web2py.com/book/default/chapter/09?search=soap#SOAP).  If
you can adapt that for soaplib it will be welcomed please.

May I request something else: I have struggled using soappy because I
could not figure out how to set http-headers.  I suspect soaplib is the
successor to soappy.  Please include a clear example of how to do that in
the client.

Regards
Johann

-- 
Johann Spies                            Telefoon: 021-808 4699
Databestuurder /  Data manager

Sentrum vir Navorsing oor Evaluasie, Wetenskap en Tegnologie
Centre for Research on Evaluation, Science and Technology 
Universiteit Stellenbosch.

     "And there were in the same country shepherds abiding 
      in the field, keeping watch over their flock by night.
      And, lo, the angel of the Lord came upon them, and the
      glory of the Lord shone round about them: and they were 
      sore afraid. And the angel said unto them, Fear not:
      for behold I bring you good tidings of great joy, which
      shall be to all people. For unto you is born this day 
      in the city of David a Saviour, which is Christ the 
      Lord."        Luke 2:8-11 


From esiotrot at gmail.com  Wed Dec 22 19:38:26 2010
From: esiotrot at gmail.com (Michael Wood)
Date: Wed, 22 Dec 2010 20:38:26 +0200
Subject: [Soap-Python] soaplib recipies
In-Reply-To: <20101222063410.GA1866@sun.ac.za>
References: <1292958548.2574.11.camel@dAlembertian>
	<20101222063410.GA1866@sun.ac.za>
Message-ID: <AANLkTi=Nkb_Dbz0siTkRsv+cOWhe2vhpZHAF6XFSy52U@mail.gmail.com>

Hi Johann

On 22 December 2010 08:34, Johann Spies <jspies at sun.ac.za> wrote:
[...]
> May I request something else: I have struggled using soappy because I
> could not figure out how to set http-headers. ?I suspect soaplib is the
> successor to soappy. ?Please include a clear example of how to do that in
> the client.

You might want to look at suds, which appears to have support for
custom HTTP headers:

https://fedorahosted.org/suds/wiki/Documentation

I haven't tried fiddling with the headers using suds, though.

-- 
Michael Wood <esiotrot at gmail.com>


From bradallen137 at gmail.com  Wed Dec 22 21:00:49 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Wed, 22 Dec 2010 14:00:49 -0600
Subject: [Soap-Python] spinning off soaplib.client, and other pieces
In-Reply-To: <AANLkTimAmbjDPJYmYonvezs2rqLHbB9_eN325-GZg+M1@mail.gmail.com>
References: <AANLkTimAmbjDPJYmYonvezs2rqLHbB9_eN325-GZg+M1@mail.gmail.com>
Message-ID: <AANLkTik=GENcDcaTxNspXi7EiRGQuuiFue8d3xUkEizj@mail.gmail.com>

Nobody raised any objections to this so we are moving forward with
these changes before the beta release.

On Thu, Dec 16, 2010 at 3:59 PM, Brad Allen <bradallen137 at gmail.com> wrote:
> Chris Austin and I were discussing the upcoming beta 2.0 release, and
> are thinking seriously about separating out the code for the soaplib
> client. Supporting the soaplib client is not a priority for us given
> that suds works well, and the client tests are failing. We don't want
> to produce a release which includes failing tests.
>
> We can treat soaplib as a namespace package, as long as the existing
> soaplib's top level __init__.py does not contain any code. That would
> open the door to other soaplib.* packages, giving us the following
> family:
>
> soaplib ?-- the main package which still includes the server,
> services, models, etc. Top level namespace entities need to be
> relocated.
> soaplib.client -- the lxml-based alternative to suds (still experimental)
> soaplib.zope -- support for Zope and accompanying tests
> soaplib.0mq ?-- support for 0mq ?and accompanying tests
>
> Each of these will be a separate repo under the soaplib organization
> in GitHub. Only soaplib and soaplib.zope will be maintained with PyPI
> releases, unless someone else volunteers to handle releases for
> soaplib.client and soaplib.0mq. I'll grant the necessary GitHub access
> to any such volunteers.
>
> Any opinions/thoughts?
>


From jspies at sun.ac.za  Thu Dec 23 07:36:25 2010
From: jspies at sun.ac.za (Johann Spies)
Date: Thu, 23 Dec 2010 08:36:25 +0200
Subject: [Soap-Python] soaplib recipies
In-Reply-To: <AANLkTi=Nkb_Dbz0siTkRsv+cOWhe2vhpZHAF6XFSy52U@mail.gmail.com>
References: <1292958548.2574.11.camel@dAlembertian>
	<20101222063410.GA1866@sun.ac.za>
	<AANLkTi=Nkb_Dbz0siTkRsv+cOWhe2vhpZHAF6XFSy52U@mail.gmail.com>
Message-ID: <20101223063625.GA4980@sun.ac.za>

Hallo Michael,

> On 22 December 2010 08:34, Johann Spies <jspies at sun.ac.za> wrote:
> [...]
> > May I request something else: I have struggled using soappy because I
> > could not figure out how to set http-headers. ?I suspect soaplib is the
> > successor to soappy. ?Please include a clear example of how to do that in
> > the client.
> 
> You might want to look at suds, which appears to have support for
> custom HTTP headers:

I am using suds because I did not succeed with soappy. It seems to me that
suds is developed by a single person.  The suds-mailing list is also not
very usable.

I was hoping that soaplib could provide an alternative.

Regards
Johann
-- 
Johann Spies                            Telefoon: 021-808 4699
Databestuurder /  Data manager

Sentrum vir Navorsing oor Evaluasie, Wetenskap en Tegnologie
Centre for Research on Evaluation, Science and Technology 
Universiteit Stellenbosch.

     "And there were in the same country shepherds abiding 
      in the field, keeping watch over their flock by night.
      And, lo, the angel of the Lord came upon them, and the
      glory of the Lord shone round about them: and they were 
      sore afraid. And the angel said unto them, Fear not:
      for behold I bring you good tidings of great joy, which
      shall be to all people. For unto you is born this day 
      in the city of David a Saviour, which is Christ the 
      Lord."        Luke 2:8-11 


From chris at sydneysys.com  Thu Dec 23 14:40:01 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 23 Dec 2010 07:40:01 -0600
Subject: [Soap-Python] soaplib recipies
In-Reply-To: <20101223063625.GA4980@sun.ac.za>
References: <1292958548.2574.11.camel@dAlembertian>
	<20101222063410.GA1866@sun.ac.za>
	<AANLkTi=Nkb_Dbz0siTkRsv+cOWhe2vhpZHAF6XFSy52U@mail.gmail.com>
	<20101223063625.GA4980@sun.ac.za>
Message-ID: <1293111601.2425.16.camel@dAlembertian>

On Thu, 2010-12-23 at 08:36 +0200, Johann Spies wrote:
> soappy.

Ahh.  I know that you can set the header using suds with a soaplib
service. try the following example from our test suite:
https://github.com/soaplib/soaplib/blob/master/src/soaplib/test/interop/test_suds.py

 
 def test_echo_in_header(self):
        in_header = self.client.factory.create('InHeader')
        in_header.s = 'a'
        in_header.i = 3
        self.client.set_options(soapheaders=in_header)
        ret = self.client.service.echo_in_header()
        self.client.set_options(soapheaders=None)
        print ret

In this case we have a declared the type 'InHeader' and it has been
published in the wsdl.




From chris at sydneysys.com  Thu Dec 23 19:05:27 2010
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 23 Dec 2010 12:05:27 -0600
Subject: [Soap-Python] Upcoming Beta Todo and a call for input.
Message-ID: <1293127527.7197.24.camel@dAlembertian>

Hi Folks,

We are looking to release soaplib-2.0-beta in January.  With this
release there will be quite a few changes from the last release.  The
biggest is the refocusing of the library back at SOAP services rather
than a generic rpc framework/library.  And, there are a few things I'd
like to ask for help from the community.  

First, I'd like to update and improve the documentation as much as
possible.  If anyone can help with this it would be greatly appreciated.
This really helps since one of our goal is to move toward Semantic
Versioning (http://semver.org/ ) and an important aspect of that is to
have a well documented API.

Second, I feel like our test coverage needs some real help.  If anyone
is willing to review the test-cases we have now and contribute further I
would be grateful.


As always, I welcome any feedback 


Cheers

Chris







From benedikt_huber at gmx.at  Tue Dec 28 21:26:55 2010
From: benedikt_huber at gmx.at (Benedikt Huber)
Date: Tue, 28 Dec 2010 21:26:55 +0100
Subject: [Soap-Python] WSDL -> Python mapping revisited
Message-ID: <4D1A480F.2030602@gmx.at>

Hello,

a few days ago Tres reported about trying to make a service from a given 
wsdl file.
Since I have the same problem I stumbled over a home-brewed script to
generate soaplib code from a wsdl file. I have not tried it, but maybe 
it helps someone.

http://stackoverflow.com/questions/3083186/generating-python-soaplib-stubs-from-wsdl

I only wanted to share this information and I wanted to know how Tres 
solved the problem.
However I think for now i am going to stick to zsi, although i would 
prefer soaplib since there are code examples on how to incorporate a 
soaplib server into django, for which i am developing.

Thank you and best regards,
Benedikt