From rocker.yandex at gmail.com  Fri Oct  1 12:49:54 2010
From: rocker.yandex at gmail.com (Alexander Kolesnikov)
Date: Fri, 1 Oct 2010 14:49:54 +0400
Subject: [Soap-Python] using soaplib with django under apache
Message-ID: <AANLkTikOLsbadj2RR8ya-JucJCaMSiTBi9QdaA+Wj-_B@mail.gmail.com>

Hi!

I have an error in my "views" module, which contains imports from soaplib.
Under django dev server it forwk fine.

Error:
Could not import project.views. Error was: DLL load failed: ?? ??????
????????? ??????

When I comment import lines I don't have this error.

Does anybody know how to solve this issue?

Best regards,
Alexander.


From rocker.yandex at gmail.com  Fri Oct  1 14:06:33 2010
From: rocker.yandex at gmail.com (Alexander Kolesnikov)
Date: Fri, 1 Oct 2010 16:06:33 +0400
Subject: [Soap-Python] using soaplib with django under apache
In-Reply-To: <AANLkTikOLsbadj2RR8ya-JucJCaMSiTBi9QdaA+Wj-_B@mail.gmail.com>
References: <AANLkTikOLsbadj2RR8ya-JucJCaMSiTBi9QdaA+Wj-_B@mail.gmail.com>
Message-ID: <AANLkTinizZu9fw4Ksc106k7z0ChgZU_qjAQwv4oqrvbK@mail.gmail.com>

mod_wsgi (pid=7696): Target WSGI script
'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'
cannot be loaded as Python module.
mod_wsgi (pid=7696): Exception occurred processing WSGI script
'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'.
Traceback (most recent call last):
   File "D:/ureg/src/identity_storage/identity_server/apache/django.wsgi",
line 13, in <module>
     from soaplib.wsgi import Application
   File "C:\\Python26\\lib\\site-packages\\soaplib\\wsgi.py", line 28,
in <module>
     from lxml import etree
 ImportError: DLL load failed: \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed
\xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.

Is this problem with lxml?


From burak.arslan at arskom.com.tr  Fri Oct  1 14:24:43 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 01 Oct 2010 15:24:43 +0300
Subject: [Soap-Python] using soaplib with django under apache
In-Reply-To: <AANLkTinizZu9fw4Ksc106k7z0ChgZU_qjAQwv4oqrvbK@mail.gmail.com>
References: <AANLkTikOLsbadj2RR8ya-JucJCaMSiTBi9QdaA+Wj-_B@mail.gmail.com>
	<AANLkTinizZu9fw4Ksc106k7z0ChgZU_qjAQwv4oqrvbK@mail.gmail.com>
Message-ID: <4CA5D30B.1000508@arskom.com.tr>

 On 10/01/10 15:06, Alexander Kolesnikov wrote:
> mod_wsgi (pid=7696): Target WSGI script
> 'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'
> cannot be loaded as Python module.
> mod_wsgi (pid=7696): Exception occurred processing WSGI script
> 'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'.
> Traceback (most recent call last):
>    File "D:/ureg/src/identity_storage/identity_server/apache/django.wsgi",
> line 13, in <module>
>      from soaplib.wsgi import Application
>    File "C:\\Python26\\lib\\site-packages\\soaplib\\wsgi.py", line 28,
> in <module>
>      from lxml import etree
>  ImportError: DLL load failed: \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed
> \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.
>
> Is this problem with lxml?

lxml is a c extension. so yes, it looks like it.


From rocker.yandex at gmail.com  Fri Oct  1 14:45:50 2010
From: rocker.yandex at gmail.com (Alexander Kolesnikov)
Date: Fri, 1 Oct 2010 16:45:50 +0400
Subject: [Soap-Python] using soaplib with django under apache
In-Reply-To: <4CA5D30B.1000508@arskom.com.tr>
References: <AANLkTikOLsbadj2RR8ya-JucJCaMSiTBi9QdaA+Wj-_B@mail.gmail.com>
	<AANLkTinizZu9fw4Ksc106k7z0ChgZU_qjAQwv4oqrvbK@mail.gmail.com>
	<4CA5D30B.1000508@arskom.com.tr>
Message-ID: <AANLkTim4yAENew_q-Mrut8wSoPc7Z7PJRvBVpZK1oFwQ@mail.gmail.com>

Error was with lxml 2.3beta1 and 2.2.8.
When I install lxml 2.2.2, all works fine.
Which version of lxml should I use with soaplib? :)

On Fri, Oct 1, 2010 at 4:24 PM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
> ?On 10/01/10 15:06, Alexander Kolesnikov wrote:
>> mod_wsgi (pid=7696): Target WSGI script
>> 'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'
>> cannot be loaded as Python module.
>> mod_wsgi (pid=7696): Exception occurred processing WSGI script
>> 'D:/ureg/src/identity_storage/identity_server/apache/django.wsgi'.
>> Traceback (most recent call last):
>> ? ?File "D:/ureg/src/identity_storage/identity_server/apache/django.wsgi",
>> line 13, in <module>
>> ? ? ?from soaplib.wsgi import Application
>> ? ?File "C:\\Python26\\lib\\site-packages\\soaplib\\wsgi.py", line 28,
>> in <module>
>> ? ? ?from lxml import etree
>> ?ImportError: DLL load failed: \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed
>> \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.
>>
>> Is this problem with lxml?
>
> lxml is a c extension. so yes, it looks like it.
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From nicholas.ruiz at members.em-a.eu  Mon Oct  4 13:50:58 2010
From: nicholas.ruiz at members.em-a.eu (Nick Ruiz)
Date: Mon, 4 Oct 2010 13:50:58 +0200
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Encoding dict objects
Message-ID: <AANLkTikUN-fbkHrwy5nop3b3UFzMVgWBRp7KfJE9UJSq@mail.gmail.com>

Hello,

I am trying to create a web service with soaplib 1.0.0-beta6 that returns a
python dict object. I just upgraded from 0.8 and am new to soaplib. Could
someone point me to a code snippet that demonstrates how to properly assign
the return type of my soap method to a dict object (and how to properly
encode/decode it)?

Thank you for your help,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101004/244614bf/attachment.html>

From chris at sydneysys.com  Mon Oct  4 17:32:57 2010
From: chris at sydneysys.com (Chris Austin)
Date: Mon, 4 Oct 2010 10:32:57 -0500
Subject: [Soap-Python] Element Attributes
Message-ID: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>

Hi All,

Does, soaplib support attributes for the elements besides nillable,
minOccurs and, maxOccurs?  Moreover, does the SOAP 1.1 spec support this?
 I've been reading through the spec (
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) this morning and I haven't
seen any direct reference.

Thanks

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101004/cbda5b2e/attachment.html>

From burak.arslan at arskom.com.tr  Mon Oct  4 17:33:39 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Mon, 04 Oct 2010 18:33:39 +0300
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Encoding dict objects
In-Reply-To: <AANLkTikUN-fbkHrwy5nop3b3UFzMVgWBRp7KfJE9UJSq@mail.gmail.com>
References: <AANLkTikUN-fbkHrwy5nop3b3UFzMVgWBRp7KfJE9UJSq@mail.gmail.com>
Message-ID: <4CA9F3D3.5030809@arskom.com.tr>

 On 10/04/10 14:50, Nick Ruiz wrote:
> Hello,
>
> I am trying to create a web service with soaplib 1.0.0-beta6 that
> returns a python dict object. I just upgraded from 0.8 and am new to
> soaplib. Could someone point me to a code snippet that demonstrates
> how to properly assign the return type of my soap method to a dict
> object (and how to properly encode/decode it)?
>


first, see here:

http://www.w3.org/2005/07/xml-schema-patterns.html#Maps

there's an AnyAsDict type that returns a specifically formed dictionary:

off the top of my head:

        root = {
            'root': [{
                'child': [{'subchild':['x']}],
                'child2': '[],
                'child3': [{
                    'subchild': ['x','y','z']
                }]
            }]
        }

would be

<root>
    <child>
        <subchild>x</subchild>
    </child>
    <child2/>
    <child3>
        <subchild>x</subchild>
        <subchild>y</subchild>
        <subchild>z</subchild>
    </child3>
</root>

does it cover your needs?




From burak.arslan at arskom.com.tr  Mon Oct  4 22:49:00 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Mon, 04 Oct 2010 23:49:00 +0300
Subject: [Soap-Python] Element Attributes
In-Reply-To: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>
References: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>
Message-ID: <4CAA3DBC.8060809@arskom.com.tr>

 On 10/04/10 18:32, Chris Austin wrote:
> Hi All,
>
> Does, soaplib support attributes for the elements besides nillable,
> minOccurs and, maxOccurs?


no, but it's quite easy to add support for new attributes. what do you need?

>  Moreover, does the SOAP 1.1 spec support this?  I've been reading
> through the spec (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) this
> morning and I haven't seen any direct reference.  
>



that's because it's a wsdl feature.

http://www.w3.org/TR/wsdl

burak


From chris at sydneysys.com  Mon Oct  4 23:54:04 2010
From: chris at sydneysys.com (Chris Austin)
Date: Mon, 4 Oct 2010 16:54:04 -0500
Subject: [Soap-Python] Element Attributes
In-Reply-To: <4CAA3DBC.8060809@arskom.com.tr>
References: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>
	<4CAA3DBC.8060809@arskom.com.tr>
Message-ID: <AANLkTin0UTHZkOiMEePRjXbodgaA1jcOTcfGBw9Ctnkc@mail.gmail.com>

Nothing in particular just yet.   But we are hoping to use
the declarative models from soaplib as the reference for our XSDs.  So, I've
been trawling through the code wrapping my head around how things function.
    Also, thanks for the link, I hadn't found that yet.

Chris

On Mon, Oct 4, 2010 at 3:49 PM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>  On 10/04/10 18:32, Chris Austin wrote:
> > Hi All,
> >
> > Does, soaplib support attributes for the elements besides nillable,
> > minOccurs and, maxOccurs?
>
>
> no, but it's quite easy to add support for new attributes. what do you
> need?
>
> >  Moreover, does the SOAP 1.1 spec support this?  I've been reading
> > through the spec (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) this
> > morning and I haven't seen any direct reference.
> >
>
>
>
> that's because it's a wsdl feature.
>
> http://www.w3.org/TR/wsdl
>
> burak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101004/bd63191c/attachment.html>

From bradallen137 at gmail.com  Tue Oct  5 00:14:47 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Mon, 4 Oct 2010 17:14:47 -0500
Subject: [Soap-Python] XML Schema functionality separable?
In-Reply-To: <19620.30554.120494.114918@gargle.gargle.HOWL>
References: <4CA43F7A.7070707@arskom.com.tr>
	<19620.30554.120494.114918@gargle.gargle.HOWL>
Message-ID: <AANLkTi=B4ApaVQ_8ctxEh-PWYxkXaK42kTSVXsJhDKou@mail.gmail.com>

On Thu, Sep 30, 2010 at 6:41 AM, Dieter Maurer <dieter at handshake.de> wrote:
> Burak Arslan wrote at 2010-9-30 10:42 +0300:
>> ... "http://pypi.python.org/pypi/PyXB/1.1.0" ...
>>it looks like the effort to extract xml schema code from soaplib will
>>not be necessary. can you share your experience if you look at this
>>package deeper?

Our developers have spent some time looking at PyXB, but soaplib's
declarative syntax for XML schemas seems to be much cleaner (though
it's not good at reading and de-serializing existing XSDs).

>>i also would like to note that wsdl has extensions to xml schema types,
>>like native arrays. so if you need strict xml schema support, the code
>>inside soaplib may not turn out to be what you want in the future.

So far the samples we have tried generate valid plain XSDs. However
I'm sure we'll bump into this as we get into arrays and attachments.
We may have to do some work on soaplib to add "vanilla XSD" support.


From ovnicraft at gmail.com  Tue Oct  5 01:32:04 2010
From: ovnicraft at gmail.com (Ovnicraft)
Date: Mon, 4 Oct 2010 18:32:04 -0500
Subject: [Soap-Python] Element Attributes
In-Reply-To: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>
References: <AANLkTikmN69JTFnSNTsR3YE--ecWj4KYr_EHN9uViPhk@mail.gmail.com>
Message-ID: <AANLkTimDZ1BBjO5HKsUQ7n8niT78mz=+GnQkuH1aX4-C@mail.gmail.com>

On Mon, Oct 4, 2010 at 10:32 AM, Chris Austin <chris at sydneysys.com> wrote:

> Hi All,
>
> Does, soaplib support attributes for the elements besides nillable,
> minOccurs and, maxOccurs?  Moreover, does the SOAP 1.1 spec support this?
>  I've been reading through the spec (
> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) this morning and I haven't
> seen any direct reference.
>

In this way, we can create a checking list with W3C especification, it will
help we can use the wiki at github.

Regards,


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


-- 
Cristian Salamea
@ovnicraft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101004/18d5fe97/attachment.html>

From nicholas.ruiz at members.em-a.eu  Tue Oct  5 14:47:19 2010
From: nicholas.ruiz at members.em-a.eu (Nick Ruiz)
Date: Tue, 5 Oct 2010 14:47:19 +0200
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
Message-ID: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>

Hi everyone,

There is documentation online on how to create web services with soaplib 0.8
within a Django web application, but the code needs to be rewritten to work
with soaplib 1.0.0-beta6. I tried updating my code to get a
slightly-modified hello world web service working under a Django
installation, but I receive the following error:

Error was: 'serverland.dashboard.api.views.worker_service' is not a
callable.

Here is my base class for creating web services (soap_handler):

from soaplib.service import DefinitionBase
from soaplib.service import rpc
from soaplib.serializers import primitive as soap_types

from django.http import HttpResponse

class DjangoSoapApp(DefinitionBase):

    def call_wrapper(self, request):
        django_response = HttpResponse()
        def start_response(status, headers):
            status, reason = status.split(' ', 1)
            django_response.status_code = int(status)
            for header, value in headers:
                django_response[header] = value
        response = super(DefinitionBase, self).call_wrapper(request.META,
start_response)
        django_response.content = "\n".join(response)

        return django_response

Here is my service (created in views.py of my Django app):

from soap_handler import DjangoSoapApp, rpc, soap_types
from soaplib.serializers.clazz import Array

class WorkerService(DjangoSoapApp):

    __tns__ = 'http://my.namespace.org/soap/'

    @rpc(soap_types.String, soap_types.Integer,
_returns=Array(soap_types.String))
    def say_hello(self, name, times):
        results = []
        for i in range(0, times):
            results.append('Hello, %s'%name)
        return results

worker_service = WorkerService()

And here are my url pattern definitions:
    url(r'^soap/', 'serverland.dashboard.api.views.worker_service'),
    url(r'^soap/service.wsdl',
'serverland.dashboard.api.views.worker_service')

How should I modify the DjangoSoapApp to enable my web service to be
callable within Django?

Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101005/ac85df5b/attachment.html>

From burak.arslan at arskom.com.tr  Tue Oct  5 15:33:47 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Tue, 05 Oct 2010 16:33:47 +0300
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
In-Reply-To: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
Message-ID: <4CAB293B.10500@arskom.com.tr>

 On 10/05/10 15:47, Nick Ruiz wrote:
> Hi everyone,
>
> There is documentation online on how to create web services with
> soaplib 0.8 within a Django web application, but the code needs to be
> rewritten to work with soaplib 1.0.0-beta6. I tried updating my code
> to get a slightly-modified hello world web service working under a
> Django installation, but I receive the following error:
>
> Error was: 'serverland.dashboard.api.views.worker_service' is not a
> callable.
>
> Here is my base class for creating web services (soap_handler):
>
> from soaplib.service import DefinitionBase
> from soaplib.service import rpc
> from soaplib.serializers import primitive as soap_types
>
> from django.http import HttpResponse
>
> class DjangoSoapApp(DefinitionBase):
>
>     def call_wrapper(self, request):
>         django_response = HttpResponse()
>         def start_response(status, headers):
>             status, reason = status.split(' ', 1)
>             django_response.status_code = int(status)
>             for header, value in headers:
>                 django_response[header] = value
>         response = super(DefinitionBase,
> self).call_wrapper(request.META, start_response)
>         django_response.content = "\n".join(response)
>
>         return django_response
>
> Here is my service (created in views.py of my Django app):
>
> from soap_handler import DjangoSoapApp, rpc, soap_types
> from soaplib.serializers.clazz import Array
>
> class WorkerService(DjangoSoapApp):
>
>     __tns__ = 'http://my.namespace.org/soap/'
>
>     @rpc(soap_types.String, soap_types.Integer,
> _returns=Array(soap_types.String))
>     def say_hello(self, name, times):
>         results = []
>         for i in range(0, times):
>             results.append('Hello, %s'%name)
>         return results
>
> worker_service = WorkerService()
>
> And here are my url pattern definitions:
>     url(r'^soap/', 'serverland.dashboard.api.views.worker_service'),
>     url(r'^soap/service.wsdl',
> 'serverland.dashboard.api.views.worker_service')
>
> How should I modify the DjangoSoapApp to enable my web service to be
> callable within Django?
>

i have never worked with django before. consequently the error does not
mean anything to me.

however, this bit is quite weird:

        response = super(DefinitionBase,
self).call_wrapper(request.META, start_response)
        django_response.content = "\n".join(response)

the response is not a string, but a native python object. you should
call the corresponding to_xml to deobjectify that, and call
etree.tostring on that to serialize it to a string. look at what happens
in wsgi.py after the call_wrapper is called.

can't django just map wsgi application to a url regex? i'd do it that way.

fwiw, i'm working on soaplib 2.0 which will be transport-agnostic. you
could as well wait for that to stabilize.

best,
burak


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101005/2eeaa2c3/attachment.html>

From venable.devin at gmail.com  Tue Oct  5 15:43:41 2010
From: venable.devin at gmail.com (Devin Venable)
Date: Tue, 5 Oct 2010 08:43:41 -0500
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
In-Reply-To: <4CAB293B.10500@arskom.com.tr>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
	<4CAB293B.10500@arskom.com.tr>
Message-ID: <AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>

Burak,

The cat's out of the bag and there are a number of people using the Django
integration recipe.  When I upgraded to soaplib 1.0 my Django integration
also quit working, and it was based on the same snippet that Nick mentioned.

Nick should check out http://djangosnippets.org/snippets/2210/, which is an
updated snippet that shows the correct (or at least workable) way to do it
using soaplib 0.9 or greater.  This worked for me.

Devin

On Tue, Oct 5, 2010 at 8:33 AM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>  On 10/05/10 15:47, Nick Ruiz wrote:
>
> Hi everyone,
>
> There is documentation online on how to create web services with soaplib
> 0.8 within a Django web application, but the code needs to be rewritten to
> work with soaplib 1.0.0-beta6. I tried updating my code to get a
> slightly-modified hello world web service working under a Django
> installation, but I receive the following error:
>
> Error was: 'serverland.dashboard.api.views.worker_service' is not a
> callable.
>
> Here is my base class for creating web services (soap_handler):
>
> from soaplib.service import DefinitionBase
> from soaplib.service import rpc
> from soaplib.serializers import primitive as soap_types
>
> from django.http import HttpResponse
>
> class DjangoSoapApp(DefinitionBase):
>
>     def call_wrapper(self, request):
>         django_response = HttpResponse()
>         def start_response(status, headers):
>             status, reason = status.split(' ', 1)
>             django_response.status_code = int(status)
>             for header, value in headers:
>                 django_response[header] = value
>         response = super(DefinitionBase, self).call_wrapper(request.META,
> start_response)
>         django_response.content = "\n".join(response)
>
>         return django_response
>
> Here is my service (created in views.py of my Django app):
>
> from soap_handler import DjangoSoapApp, rpc, soap_types
> from soaplib.serializers.clazz import Array
>
> class WorkerService(DjangoSoapApp):
>
>     __tns__ = 'http://my.namespace.org/soap/'
>
>     @rpc(soap_types.String, soap_types.Integer,
> _returns=Array(soap_types.String))
>     def say_hello(self, name, times):
>         results = []
>         for i in range(0, times):
>             results.append('Hello, %s'%name)
>         return results
>
> worker_service = WorkerService()
>
> And here are my url pattern definitions:
>     url(r'^soap/', 'serverland.dashboard.api.views.worker_service'),
>     url(r'^soap/service.wsdl',
> 'serverland.dashboard.api.views.worker_service')
>
> How should I modify the DjangoSoapApp to enable my web service to be
> callable within Django?
>
>
> i have never worked with django before. consequently the error does not
> mean anything to me.
>
> however, this bit is quite weird:
>
>
>         response = super(DefinitionBase, self).call_wrapper(request.META,
> start_response)
>         django_response.content = "\n".join(response)
>
> the response is not a string, but a native python object. you should call
> the corresponding to_xml to deobjectify that, and call etree.tostring on
> that to serialize it to a string. look at what happens in wsgi.py after the
> call_wrapper is called.
>
> can't django just map wsgi application to a url regex? i'd do it that way.
>
> fwiw, i'm working on soaplib 2.0 which will be transport-agnostic. you
> could as well wait for that to stabilize.
>
> best,
> burak
>
>
>
> _______________________________________________
> 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/20101005/c2f349b0/attachment.html>

From ben.lopatin at wellfireinteractive.com  Tue Oct  5 15:54:23 2010
From: ben.lopatin at wellfireinteractive.com (Ben Lopatin)
Date: Tue, 5 Oct 2010 09:54:23 -0400
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
In-Reply-To: <AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
	<4CAB293B.10500@arskom.com.tr>
	<AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>
Message-ID: <AANLkTimfU0fzcUt0+kWQgfDf8HHRRUJeD+uRO7mUc+4N@mail.gmail.com>

All,

I haven't looked at what's changed from 0.9.2 to 1.0, but here's a
generalization of how I used soaplib 0.9.2 with Django:
http://gist.github.com/499210

The only thing that I had to work around was a finicky .NET client consumer,
for which I wrote a modified static WSDL file.

Ben

On Tue, Oct 5, 2010 at 9:43 AM, Devin Venable <venable.devin at gmail.com>wrote:

> Burak,
>
> The cat's out of the bag and there are a number of people using the Django
> integration recipe.  When I upgraded to soaplib 1.0 my Django integration
> also quit working, and it was based on the same snippet that Nick mentioned.
>
> Nick should check out http://djangosnippets.org/snippets/2210/, which is
> an updated snippet that shows the correct (or at least workable) way to do
> it using soaplib 0.9 or greater.  This worked for me.
>
> Devin
>
> On Tue, Oct 5, 2010 at 8:33 AM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:
>
>>  On 10/05/10 15:47, Nick Ruiz wrote:
>>
>> Hi everyone,
>>
>> There is documentation online on how to create web services with soaplib
>> 0.8 within a Django web application, but the code needs to be rewritten to
>> work with soaplib 1.0.0-beta6. I tried updating my code to get a
>> slightly-modified hello world web service working under a Django
>> installation, but I receive the following error:
>>
>> Error was: 'serverland.dashboard.api.views.worker_service' is not a
>> callable.
>>
>> Here is my base class for creating web services (soap_handler):
>>
>> from soaplib.service import DefinitionBase
>> from soaplib.service import rpc
>> from soaplib.serializers import primitive as soap_types
>>
>> from django.http import HttpResponse
>>
>> class DjangoSoapApp(DefinitionBase):
>>
>>     def call_wrapper(self, request):
>>         django_response = HttpResponse()
>>         def start_response(status, headers):
>>             status, reason = status.split(' ', 1)
>>             django_response.status_code = int(status)
>>             for header, value in headers:
>>                 django_response[header] = value
>>         response = super(DefinitionBase, self).call_wrapper(request.META,
>> start_response)
>>         django_response.content = "\n".join(response)
>>
>>         return django_response
>>
>> Here is my service (created in views.py of my Django app):
>>
>> from soap_handler import DjangoSoapApp, rpc, soap_types
>> from soaplib.serializers.clazz import Array
>>
>> class WorkerService(DjangoSoapApp):
>>
>>     __tns__ = 'http://my.namespace.org/soap/'
>>
>>     @rpc(soap_types.String, soap_types.Integer,
>> _returns=Array(soap_types.String))
>>     def say_hello(self, name, times):
>>         results = []
>>         for i in range(0, times):
>>             results.append('Hello, %s'%name)
>>         return results
>>
>> worker_service = WorkerService()
>>
>> And here are my url pattern definitions:
>>     url(r'^soap/', 'serverland.dashboard.api.views.worker_service'),
>>     url(r'^soap/service.wsdl',
>> 'serverland.dashboard.api.views.worker_service')
>>
>> How should I modify the DjangoSoapApp to enable my web service to be
>> callable within Django?
>>
>>
>> i have never worked with django before. consequently the error does not
>> mean anything to me.
>>
>> however, this bit is quite weird:
>>
>>
>>         response = super(DefinitionBase, self).call_wrapper(request.META,
>> start_response)
>>         django_response.content = "\n".join(response)
>>
>> the response is not a string, but a native python object. you should call
>> the corresponding to_xml to deobjectify that, and call etree.tostring on
>> that to serialize it to a string. look at what happens in wsgi.py after the
>> call_wrapper is called.
>>
>> can't django just map wsgi application to a url regex? i'd do it that way.
>>
>> fwiw, i'm working on soaplib 2.0 which will be transport-agnostic. you
>> could as well wait for that to stabilize.
>>
>> best,
>> burak
>>
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Ben Lopatin
www.wellfireinteractive.com
ben.lopatin at wellfireinteractive.com
571.482.8801
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101005/73a57d80/attachment.html>

From burak.arslan at arskom.com.tr  Tue Oct  5 16:21:11 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Tue, 05 Oct 2010 17:21:11 +0300
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
In-Reply-To: <AANLkTimfU0fzcUt0+kWQgfDf8HHRRUJeD+uRO7mUc+4N@mail.gmail.com>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>	<4CAB293B.10500@arskom.com.tr>	<AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>
	<AANLkTimfU0fzcUt0+kWQgfDf8HHRRUJeD+uRO7mUc+4N@mail.gmail.com>
Message-ID: <4CAB3457.8070601@arskom.com.tr>

 On 10/05/10 16:54, Ben Lopatin wrote:
> All,
>
> I haven't looked at what's changed from 0.9.2 to 1.0, but here's a
> generalization of how I used soaplib 0.9.2 with Django:
> http://gist.github.com/499210
>

fwiw, i didn't dare taking soaplib into production before 1.0.

at first glance, i think this should work. can you contribute this in
the 1_0 examples directory in a fork of yours so that i pull it and have
a look at it? (adding a small readme on how to get it running would also
be helpful)

> The only thing that I had to work around was a finicky .NET client
> consumer, for which I wrote a modified static WSDL file.
>

can you elaborate on this? does it have anything to do with
http://github.com/arskom/soaplib/issues#issue/7 ?

thanks
burak

> Ben
>
> On Tue, Oct 5, 2010 at 9:43 AM, Devin Venable <venable.devin at gmail.com
> <mailto:venable.devin at gmail.com>> wrote:
>
>     Burak,
>
>     The cat's out of the bag and there are a number of people using
>     the Django integration recipe.  When I upgraded to soaplib 1.0 my
>     Django integration also quit working, and it was based on the same
>     snippet that Nick mentioned.
>
>     Nick should check out http://djangosnippets.org/snippets/2210/,
>     which is an updated snippet that shows the correct (or at least
>     workable) way to do it using soaplib 0.9 or greater.  This worked
>     for me.
>
>     Devin
>
>     On Tue, Oct 5, 2010 at 8:33 AM, Burak Arslan
>     <burak.arslan at arskom.com.tr <mailto:burak.arslan at arskom.com.tr>>
>     wrote:
>
>         On 10/05/10 15:47, Nick Ruiz wrote:
>>         Hi everyone,
>>
>>         There is documentation online on how to create web services
>>         with soaplib 0.8 within a Django web application, but the
>>         code needs to be rewritten to work with soaplib 1.0.0-beta6.
>>         I tried updating my code to get a slightly-modified hello
>>         world web service working under a Django installation, but I
>>         receive the following error:
>>
>>         Error was: 'serverland.dashboard.api.views.worker_service' is
>>         not a callable.
>>
>>         Here is my base class for creating web services (soap_handler):
>>
>>         from soaplib.service import DefinitionBase
>>         from soaplib.service import rpc
>>         from soaplib.serializers import primitive as soap_types
>>
>>         from django.http import HttpResponse
>>
>>         class DjangoSoapApp(DefinitionBase):
>>
>>             def call_wrapper(self, request):
>>                 django_response = HttpResponse()
>>                 def start_response(status, headers):
>>                     status, reason = status.split(' ', 1)
>>                     django_response.status_code = int(status)
>>                     for header, value in headers:
>>                         django_response[header] = value
>>                 response = super(DefinitionBase,
>>         self).call_wrapper(request.META, start_response)
>>                 django_response.content = "\n".join(response)
>>
>>                 return django_response
>>
>>         Here is my service (created in views.py of my Django app):
>>
>>         from soap_handler import DjangoSoapApp, rpc, soap_types
>>         from soaplib.serializers.clazz import Array
>>
>>         class WorkerService(DjangoSoapApp):
>>
>>             __tns__ = 'http://my.namespace.org/soap/'
>>
>>             @rpc(soap_types.String, soap_types.Integer,
>>         _returns=Array(soap_types.String))
>>             def say_hello(self, name, times):
>>                 results = []
>>                 for i in range(0, times):
>>                     results.append('Hello, %s'%name)
>>                 return results
>>
>>         worker_service = WorkerService()
>>
>>         And here are my url pattern definitions:
>>             url(r'^soap/',
>>         'serverland.dashboard.api.views.worker_service'),
>>             url(r'^soap/service.wsdl',
>>         'serverland.dashboard.api.views.worker_service')
>>
>>         How should I modify the DjangoSoapApp to enable my web
>>         service to be callable within Django?
>>
>
>         i have never worked with django before. consequently the error
>         does not mean anything to me.
>
>         however, this bit is quite weird:
>
>
>                 response = super(DefinitionBase,
>         self).call_wrapper(request.META, start_response)
>                 django_response.content = "\n".join(response)
>
>         the response is not a string, but a native python object. you
>         should call the corresponding to_xml to deobjectify that, and
>         call etree.tostring on that to serialize it to a string. look
>         at what happens in wsgi.py after the call_wrapper is called.
>
>         can't django just map wsgi application to a url regex? i'd do
>         it that way.
>
>         fwiw, i'm working on soaplib 2.0 which will be
>         transport-agnostic. you could as well wait for that to stabilize.
>
>         best,
>         burak
>
>
>
>         _______________________________________________
>         Soap mailing list
>         Soap at python.org <mailto:Soap at python.org>
>         http://mail.python.org/mailman/listinfo/soap
>
>
>
>     _______________________________________________
>     Soap mailing list
>     Soap at python.org <mailto:Soap at python.org>
>     http://mail.python.org/mailman/listinfo/soap
>
>
>
>
> -- 
> Ben Lopatin
> www.wellfireinteractive.com <http://www.wellfireinteractive.com>
> ben.lopatin at wellfireinteractive.com
> <mailto:ben.lopatin at wellfireinteractive.com>
> 571.482.8801

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101005/c2c823bb/attachment.html>

From burak.arslan at arskom.com.tr  Wed Oct  6 00:39:22 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Wed, 06 Oct 2010 01:39:22 +0300
Subject: [Soap-Python] separation of concers
Message-ID: <4CABA91A.8000402@arskom.com.tr>


hi,

i've taken a first step towards separating the wsgi logic from the soap
logic. it's in the current master branch.

please have a look at the new soaplib.Application interface:
http://github.com/arskom/soaplib/issues/#issue/10/comment/449913

and share your thoughts.

thanks,
burak




From ben.lopatin at wellfireinteractive.com  Wed Oct  6 04:31:52 2010
From: ben.lopatin at wellfireinteractive.com (Ben Lopatin)
Date: Tue, 5 Oct 2010 22:31:52 -0400
Subject: [Soap-Python] =?utf-8?Q?Re=3A_?=soaplib 1.0.0-beta6 - Integration
	with Django
In-Reply-To: <4CAB3457.8070601@arskom.com.tr>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
	<4CAB293B.10500@arskom.com.tr>
	<AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>
	<AANLkTimfU0fzcUt0+kWQgfDf8HHRRUJeD+uRO7mUc+4N@mail.gmail.com>
	<4CAB3457.8070601@arskom.com.tr>
Message-ID: <06469C9F85424C3BB050CF61518E5B99@wellfireinteractive.com>


        
        
        Burak,The primary problem with this particular client application was that the soaplib WSDL declared the minOccurs attribute value for a response value as '0'. I'm not sure to what degree that was a .NET issue and a specific client application issue (I tried against what I understood to be third-party .NET testing services and by and large they fared okay).I would add that .NET compatability is probably important for most SOAP applications, as if you're dealing with services or clients that require SOAP you're probably dealing with 'enterprise' systems which all too often means .NET.I'd be happy to add that example into my fork. I'll see how it fares with the latest updates.Ben
        
		
		
        On Tuesday, October 5, 2010 at 10:21 AM, Burak Arslan wrote:
        
            

    On 10/05/10 16:54, Ben Lopatin wrote:
    
      All,
      
      
      I haven't looked at what's changed from 0.9.2 to 1.0, but here's a
      generalization of how I used soaplib 0.9.2 with Django: http://gist.github.com/499210
      
        
      
    
    fwiw, i didn't dare taking soaplib into production before 1.0. 
    
    at first glance, i think this should work. can you contribute this
    in the 1_0 examples directory in a fork of yours so that i pull it
    and have a look at it? (adding a small readme on how to get it
    running would also be helpful)
    
      The only thing that I had to work around was a finicky .NET
        client consumer, for which I wrote a modified static WSDL file.
        
        
      
    
    can you elaborate on this? does it have anything to do with
    http://github.com/arskom/soaplib/issues#issue/7 ?
    
    thanks
    burak
    
      
        Ben
        
          On Tue, Oct 5, 2010 at 9:43 AM, Devin
            Venable <venable.devin at gmail.com>
            wrote:Burak,
              
              
              The cat's out of the bag and there are a number of
                people using the Django integration recipe. ?When I
                upgraded to soaplib 1.0 my Django integration also quit
                working, and it was based on the same snippet that Nick
                mentioned.
              
              
              Nick should check out?http://djangosnippets.org/snippets/2210/,
                which is an updated snippet that shows the correct (or
                at least workable) way to do it using soaplib 0.9 or
                greater. ?This worked for me.
              
              
              Devin
                
                
                  
                    On Tue, Oct 5, 2010 at 8:33 AM,
                      Burak Arslan <burak.arslan at arskom.com.tr>
                      wrote:
                    
                  
                    
                      
                        
                          
                             On 10/05/10 15:47, Nick Ruiz wrote:
                              Hi everyone,
                                
                                There is documentation online on how to
                                create web services with soaplib 0.8
                                within a Django web application, but the
                                code needs to be rewritten to work with
                                soaplib 1.0.0-beta6. I tried updating my
                                code to get a slightly-modified hello
                                world web service working under a Django
                                installation, but I receive the
                                following error:
                                
                                Error was:
                                'serverland.dashboard.api.views.worker_service'
                                is not a callable.
                                
                                Here is my base class for creating web
                                services (soap_handler):
                                
                                from soaplib.service
                                  import DefinitionBase
                                from soaplib.service
                                  import rpc
                                from
                                  soaplib.serializers import primitive
                                  as soap_types
                                
                                from django.http
                                  import HttpResponse
                                
                                class
                                  DjangoSoapApp(DefinitionBase):
                                
                                ??? def
                                  call_wrapper(self, request):
                                ???????
                                  django_response = HttpResponse()
                                ??????? def
                                  start_response(status, headers):
                                ??????????? status,
                                  reason = status.split(' ', 1)
                                ???????????
                                  django_response.status_code =
                                  int(status)
                                ??????????? for
                                  header, value in headers:
                                ???????????????
                                  django_response[header] = value
                                ??????? response =
                                  super(DefinitionBase,
                                  self).call_wrapper(request.META,
                                  start_response)
                                ???????
                                  django_response.content =
                                  "\n".join(response)
                                
                                ??????? return
                                  django_response
                                
                                Here is my service (created in views.py
                                of my Django app):
                                
                                from soap_handler
                                  import DjangoSoapApp, rpc, soap_types
                                from
                                  soaplib.serializers.clazz import Array
                                
                                class
                                  WorkerService(DjangoSoapApp):
                                
                                ??? __tns__ = 'http://my.namespace.org/soap/'
                                
                                ???
                                  @rpc(soap_types.String,
                                  soap_types.Integer,
                                  _returns=Array(soap_types.String))
                                ??? def
                                  say_hello(self, name, times):
                                ??????? results = []
                                ??????? for i in
                                  range(0, times):
                                ???????????
                                  results.append('Hello, %s'%name)
                                ??????? return results
                                
                                worker_service =
                                  WorkerService()
                                
                                And here are my url pattern definitions:
                                ??? url(r'^soap/',
                                  'serverland.dashboard.api.views.worker_service'),
                                ???
                                  url(r'^soap/service.wsdl',
                                  'serverland.dashboard.api.views.worker_service')
                                
                                How should I modify the DjangoSoapApp to
                                enable my web service to be callable
                                within Django?
                                
                              
                            
                          
                          i have never worked with django before.
                          consequently the error does not mean anything
                          to me.
                          
                          however, this bit is quite weird:
                          
                            
                            ??????? response =
                              super(DefinitionBase,
                              self).call_wrapper(request.META,
                              start_response)
                            ???????
                              django_response.content =
                              "\n".join(response)
                            
                          
                          the response is not a string, but a native
                          python object. you should call the
                          corresponding to_xml to deobjectify that, and
                          call etree.tostring on that to serialize it to
                          a string. look at what happens in wsgi.py
                          after the call_wrapper is called.
                          
                          can't django just map wsgi application to a
                          url regex? i'd do it that way.
                          
                          fwiw, i'm working on soaplib 2.0 which will be
                          transport-agnostic. you could as well wait for
                          that to stabilize.
                          
                          best,
                          burak
                          
                          
                        
                        
                      
                    
                    _______________________________________________
                    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
              
            
          
          
          
          -- 
          Ben Lopatin
          www.wellfireinteractive.com
          ben.lopatin at wellfireinteractive.com
          571.482.8801
        
      
    
  

_______________________________________________Soap mailing listSoap at python.orghttp://mail.python.org/mailman/listinfo/soap
			
			
			
			
        
		
		
    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101005/caa076bd/attachment.html>

From bradallen137 at gmail.com  Wed Oct  6 17:46:21 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Wed, 6 Oct 2010 10:46:21 -0500
Subject: [Soap-Python] soaplib versioning and community process
Message-ID: <AANLkTikxjDnGdyAn4-Ey+muGuNsgUVvQhk7Mk=3+c-G1@mail.gmail.com>

Burak,

It's great to see all the work you're putting into soaplib, but I'm
concerned about the approach to versioning and think we need more of a
community process for releases.

In another thread you mentioned starting work on 2.0 release, and now
I see that the 2.0 is now released on PyPI.  This seems
premature...actually I thought 1.0 was premature since the API was
still changing, the beta was released without tests passing, and I
doubt if 1.0 has been released long enough for it to mature, or even
get rolled into production anywhere.

There are a certain set of traditional expectations about a 1.0
release. Look at how long it took Django to get to 1.0, for example.

Now that 1.0 and 2.0 have been released on PyPI, does that mean we
can't go back in time and do-over?


From burak.arslan at arskom.com.tr  Wed Oct  6 23:21:09 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 00:21:09 +0300
Subject: [Soap-Python] soaplib 1.0.0-beta6 - Integration with Django
In-Reply-To: <AANLkTimmXEw+jyb7jhfGUFMfZXgLm-bs5V7EDT5V=h-E@mail.gmail.com>
References: <AANLkTi=6DwaT=+cpN_sgsCU=nqiE=P6pCGaTQkCkNW4d@mail.gmail.com>
	<4CAB293B.10500@arskom.com.tr>
	<AANLkTinRMZse_HifX45O+ZFs1gjczbo4c=BxCmPaDbbA@mail.gmail.com>
	<AANLkTimmXEw+jyb7jhfGUFMfZXgLm-bs5V7EDT5V=h-E@mail.gmail.com>
Message-ID: <4CACE845.1080605@arskom.com.tr>

 On 10/06/10 15:59, Nick Ruiz wrote:
> Thanks for your help, guys. Another question: In soaplib 0.8, there
> used to be a soaplib.client class that allowed you to easily test web
> service calls. I'm not really following the code well in the
> test_service.py script to see how I write a script to call my web
> service. Can someone give me a hint?
>

soaplib 1.x has no client support. just use suds.

> Also, can soaplib currently be used by a client to consume web
> services, or is it necessary to use another python library to discover
> WSDLs and invoke web services?

nope. soaplib never had the ability to parse wsdl. really, just use suds.

burak


From burak.arslan at arskom.com.tr  Thu Oct  7 10:27:48 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 7 Oct 2010 11:27:48 +0300 (EEST)
Subject: [Soap-Python] soaplib versioning and community process
Message-ID: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>

brad, all,

i was going to talk about this. thanks for expressing those concerns and
provoking me to do it sooner.

On 10/06/10 18:46, Brad Allen wrote:
> Burak,
>
> It's great to see all the work you're putting into soaplib, but I'm
concerned about the approach to versioning and think we need more of a
community process for releases.
>
> In another thread you mentioned starting work on 2.0 release, and now I
see that the 2.0 is now released on PyPI.  This seems
> premature...actually I thought 1.0 was premature since the API was still
changing, the beta was released without tests passing, and I doubt if
1.0 has been released long enough for it to mature, or even get rolled
into production anywhere.
>

here's what's on my book about release tags:

alpha: kind of works. stable? maybe. maybe not.
beta: has known bugs, but otherwise stable
release candidate: passes all tests, no known bugs, torture it!
release: yay! get me booze :)

so, 2.0 is alpha. i can't make it clearer that it's not ready for
production yet. if you don't want to run my half-baked alpha software, do
this:

easy_install -U "soaplib<=1.0"

in all honesty, i don't think that's a hurdle.

as for the stabilization and maturity; not only soaplib 1.0 is not mature,
but it has known bugs. so, by the above definition, it's a beta-quality
software. the bad news is that i just can't spend any more resources on
the 1.0 branch. i will of course review and integrate the patches, but
that's going to have to be it.

so anybody who wants to see a stable 1.0 release should start fixing those
tests and send pull requests for the 1_0 branch my way. otherwise, i'm
afraid soaplib 1.0 will be stuck in beta-limbo forever.


> There are a certain set of traditional expectations about a 1.0
> release. Look at how long it took Django to get to 1.0, for example.
>

django didn't have a spec to implement. we do, and my judgement was that
the subset implemented in soaplib 1.0 already covered the basic needs. you
may not agree, and i'll respect that. but just remember what i said: it's
just a first step towards implementing a complex protocol.

> Now that 1.0 and 2.0 have been released on PyPI, does that mean we can't
go back in time and do-over?

sorry, what do you mean? i'm not familiar with this expression.

best regards,
burak







From burak.arslan at arskom.com.tr  Thu Oct  7 11:08:38 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 12:08:38 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
Message-ID: <1286442518.1384.12.camel@Nokia-N900>

----- Original message -----
> as for the stabilization and maturity; not only soaplib 1.0 is not
> mature, but it has known bugs. so, by the above definition, it's a
> beta-quality software. the bad news is that i just can't spend any more
> resources on the 1.0 branch. i will of course review and integrate the
> patches, but that's going to have to be it.
> 
> so anybody who wants to see a stable 1.0 release should start fixing
> those tests and send pull requests for the 1_0 branch my way. otherwise,
> i'm afraid soaplib 1.0 will be stuck in beta-limbo forever.
> 

by the way, that's going to be the case for any soaplib release done by me. i'm happy to do the major chunk of work, but i just can't claim soaplib to be stable without getting feedback from the community. i can't get in your shoes and test it in your environment. so it's not "i can't stabilize soaplib because i have better things to do" but it's "i can't stabilize soaplib because i really can't do it by myself"

i hope what's in my mind is clear enough.

best regards,
burak
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101007/f75c247b/attachment.html>

From dieter at handshake.de  Thu Oct  7 12:40:10 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Thu, 7 Oct 2010 12:40:10 +0200
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
Message-ID: <19629.41866.960960.664321@gargle.gargle.HOWL>

Burak Arslan wrote at 2010-10-7 11:27 +0300:
> ...
>so, 2.0 is alpha. i can't make it clearer that it's not ready for
>production yet. if you don't want to run my half-baked alpha software, do
>this:

It may seem surprising, that 2.0 is started before 1.0 is finally released.

This indicates a great deal of instability in the development process
(major versions are often associated with incompatible changes) --
not a good sign for the adoption of a package...


>
>easy_install -U "soaplib<=1.0"

This will get soaplib at or before 1.0, but not e.g. "1.0p1" (patch 1).

There is no fully reliably way to specify "latest (stable) 1.x release" --
a "setuptools" limitation. One might try something like "<=1.999999".

The missing feature to easily restrict to stable versions with "easy_install"
causes some poeple to recommend to release only stable versions to "PyPI".
I have often got unstable versions with indeed have broken things for me...

>in all honesty, i don't think that's a hurdle.

The slightly suboptimal version specification above, may show the
contrary ;-)



--
Dieter


From burak.arslan at arskom.com.tr  Thu Oct  7 13:27:15 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 14:27:15 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <19629.41866.960960.664321@gargle.gargle.HOWL>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
	<19629.41866.960960.664321@gargle.gargle.HOWL>
Message-ID: <4CADAE93.4030105@arskom.com.tr>

 On 10/07/10 13:40, Dieter Maurer wrote:
> Burak Arslan wrote at 2010-10-7 11:27 +0300:
>> ...
>> so, 2.0 is alpha. i can't make it clearer that it's not ready for
>> production yet. if you don't want to run my half-baked alpha software, do
>> this:
> It may seem surprising, that 2.0 is started before 1.0 is finally released.
>

hello dieter,

soaplib development never stopped. i just created a branch before
starting another overhaul, so that those who need a stable version
sooner rather than later have something to work with. did you see the
diff stat between 1_0 and master?

$ git diff --stat 1_0 master
 README.md                                   |   12 +-
 doc/source/index.rst                        |    1 +
 setup.cfg                                   |    2 +-
 setup.py                                    |    2 +-
 src/soaplib/__init__.py                     |   45 +--
 src/soaplib/_base.py                        |  719
+++++++++++++++++++++++++++
 src/soaplib/mime.py                         |  290 +++++++++++
 src/soaplib/serializers/base.py             |   24 +-
 src/soaplib/serializers/clazz.py            |   13 +-
 src/soaplib/serializers/enum.py             |    5 +-
 src/soaplib/serializers/exception.py        |   22 +-
 src/soaplib/serializers/primitive.py        |   15 +-
 src/soaplib/service.py                      |  297 ++++++-----
 src/soaplib/soap.py                         |  313 +-----------
 src/soaplib/test/interop/server/_service.py |   17 +-
 src/soaplib/test/interop/server/basic.py    |    2 +-
 src/soaplib/test/interop/test_suds.py       |   14 +
 src/soaplib/test/serializers/test_enum.py   |    5 +-
 src/soaplib/test/test_soap.py               |    2 +-
 src/soaplib/wsgi.py                         |  655
+++----------------------
 20 files changed, 1339 insertions(+), 1116 deletions(-)

it touches almost the whole code base! the 1_0 branch did see some
real-world testing, and i did not want to throw that all away. i
explained why i can't stabilize soaplib-1.0 in another message.

i have to work at my own pace. that's the best i can do for everybody
else without distorting my own schedule.

> This indicates a great deal of instability in the development process
> (major versions are often associated with incompatible changes) --
> not a good sign for the adoption of a package...
>
>

i disagree. i think fast iteration is a positive sign.

>> easy_install -U "soaplib<=1.0"
> This will get soaplib at or before 1.0, but not e.g. "1.0p1" (patch 1).
>
> There is no fully reliably way to specify "latest (stable) 1.x release" --
> a "setuptools" limitation. One might try something like "<=1.999999".
>
> The missing feature to easily restrict to stable versions with "easy_install"
> causes some poeple to recommend to release only stable versions to "PyPI".
> I have often got unstable versions with indeed have broken things for me...
>
>> in all honesty, i don't think that's a hurdle.
> The slightly suboptimal version specification above, may show the
> contrary ;-)
>
>

those complaints belong to the setuptools issue tracker. you should know
the limitations of your tools and take better care not to break your
production.

best regards,
burak






From burak.arslan at arskom.com.tr  Thu Oct  7 00:53:47 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 01:53:47 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <AANLkTikxjDnGdyAn4-Ey+muGuNsgUVvQhk7Mk=3+c-G1@mail.gmail.com>
References: <AANLkTikxjDnGdyAn4-Ey+muGuNsgUVvQhk7Mk=3+c-G1@mail.gmail.com>
Message-ID: <4CACFDFB.8060904@arskom.com.tr>


brad, all,

i was going to talk about this. thanks for expressing those concerns and
provoking me to do it sooner.

On 10/06/10 18:46, Brad Allen wrote:
> Burak,
>
> It's great to see all the work you're putting into soaplib, but I'm
> concerned about the approach to versioning and think we need more of a
> community process for releases.
>
> In another thread you mentioned starting work on 2.0 release, and now
> I see that the 2.0 is now released on PyPI.  This seems
> premature...actually I thought 1.0 was premature since the API was
> still changing, the beta was released without tests passing, and I
> doubt if 1.0 has been released long enough for it to mature, or even
> get rolled into production anywhere.
>

here's what's on my book about release tags:

alpha: kind of works. stable? maybe. maybe not.
beta: has known bugs, but otherwise stable
release candidate: passes all tests, no known bugs, torture it!
release: yay! get me booze :)

so, 2.0 is alpha. i can't make it clearer that it's not ready for
production yet. if you don't want to run my half-baked alpha software,
do this:

easy_install -U "soaplib<=1.0"

in all honesty, i don't think that's a hurdle.

as for the stabilization and maturity; not only soaplib 1.0 is not
mature, but it has known bugs. so, by the above definition, it's a
beta-quality software. the bad news is that i just can't spend any more
resources on the 1.0 branch. i will of course review and integrate the
patches, but that's going to have to be it.

so anybody who wants to see a stable 1.0 release should start fixing
those tests and send pull requests for the 1_0 branch my way. otherwise,
i'm afraid soaplib 1.0 will be stuck in beta-limbo forever.


> There are a certain set of traditional expectations about a 1.0
> release. Look at how long it took Django to get to 1.0, for example.
>

django didn't have a spec to implement. we do, and my judgement was that
the subset implemented in soaplib 1.0 already covered the basic needs.
you may not agree, and i'll respect that. but just remember what i said:
it's just a first step towards implementing a complex protocol.

> Now that 1.0 and 2.0 have been released on PyPI, does that mean we
> can't go back in time and do-over?

sorry, what do you mean? i'm not familiar with this expression.

best regards,
burak




From burak.arslan at arskom.com.tr  Thu Oct  7 14:01:55 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 15:01:55 +0300
Subject: [Soap-Python] soaplib: patch: out_type list
In-Reply-To: <AANLkTimsw_Mw_ERjP9Vq3s4nH2tamPMGFc2SvWdTh+Uz@mail.gmail.com>
References: <AANLkTimsw_Mw_ERjP9Vq3s4nH2tamPMGFc2SvWdTh+Uz@mail.gmail.com>
Message-ID: <4CADB6B3.3050900@arskom.com.tr>

 Hello Raymond,

Thank you very much for the patch, the test case and the detailed
explanation. Your work will be integrated to both 1.0 and trunk branches
and will be shipped in the next releases.

Best regards,
Burak

ps: be sure to subscribe to soap at python.org (cc'd) to make sure you get
the latest news about python-related soap matters.


On 10/06/10 18:13, Raymond Penners wrote:
> Hi,
>
> I am implementing a soap service with a predefined (legacy) WSDL in
> python using soaplib. I ran into an issue for which I have cooked up a
> patch that I would like to hear your opinion on.
>
> The WSDL is defined in such a way that when you invoke a "getRoles"
> method one must return a SOAP response with the out parameters
> directly embedded into the <getRolesResponse>, not in a
> <getRolesResult> (nested in the <getRolesResponse>).
>
> So I dove into soaplib internals and found out this could be
> accomplished like this:
>
> class SomeService( DefinitionBase):
>     @rpc(String, Integer, _returns=[Integer, String, Integer,
> Array(Enum("MEMBER", type_name="role"))],
>          _out_variable_names=['resultCode','resultDescription','transactionId',
> 'roles' ])
>     def getRoles(self, token, userId):
>         return [1, "Test", 123, ["MEMBER"]]
>
> However, when attempting to invoke a call using the above service I
> run into an assert (for both 1.0.0-beta6 and 2.0 alpha):
>
> assert len(out_type) == 1   # __handle_soap_request of wsgi.py (soaplib 1.0.0)
>
> I have patched the code (soaplib 1.0) and it is now working properly.
> Is the patch the proper way to address this problem? And if so, could
> you please patch this upstream?
>
> Thanks,



From venable.devin at gmail.com  Thu Oct  7 14:31:39 2010
From: venable.devin at gmail.com (Devin Venable)
Date: Thu, 7 Oct 2010 07:31:39 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CADAE93.4030105@arskom.com.tr>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
	<19629.41866.960960.664321@gargle.gargle.HOWL>
	<4CADAE93.4030105@arskom.com.tr>
Message-ID: <AANLkTinSNnSf9mPZ=LvnPUUSKgt_CGqHw0op+w=49LG_@mail.gmail.com>

Burak and Dieter and all,

I would encourage everyone to be constructive and not critical in tone when
discussing what ought to be done about versioning.  I think Dieter may have
a few good points.  I also think soaplib is very useful, so let's do what we
can to get these issues worked out.

In an earlier post I mentioned that I had been using soaplib and that I had
installed it from the apt repositories using Ubuntu.  For me, once I see a
package in the Ubuntu repositories I assume that the code is fairly stable
and useful, otherwise the package maintainers wouldn't have included it.  So
what makes a package maintainer decide that the library is ready for
inclusion?  Actually, I don't know the answer to this question (because
there is a PyPI package for it?); I just know that once a library shows up
there, I expect that it is production ready.  Obviously the library is being
used in the real world once it shows up there.

I wrote some production software that uses the version in the apt
repositories.  Anyone anywhere in the world running Ubuntu has access to
this version of the library and I imagine that I'm not the only one who is
making use of it:

$apt-cache search soaplib
python-soaplib - Python library for writing and calling soap web services

The version in apt is 0.8.  1.0 is not backwards compatible with 0.8, which
was a problem for me and will be for others because when and if 1.0 ever
makes it into the apt repository, those of us who have been using the
library will see our code break.  So backwards compatibility is really
important and working out the versioning scheme is really important.

If 2.0 is really an experimental branch, perhaps it can be re-tagged as
such.  I'm no pro on versioning schemes, so perhaps Dieter has suggestions
or guidelines.

There is no other library for Python quite like soaplib, and soaplib
provides a very important part of the web services architecture for those of
us who and forced into integrating with those who use SOAP as their web
communication protocol.  So let's figure out the right way to version and
release this so that the library will continue to be adopted by python users
worldwide.

Devin




On Thu, Oct 7, 2010 at 6:27 AM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>  On 10/07/10 13:40, Dieter Maurer wrote:
> > Burak Arslan wrote at 2010-10-7 11:27 +0300:
> >> ...
> >> so, 2.0 is alpha. i can't make it clearer that it's not ready for
> >> production yet. if you don't want to run my half-baked alpha software,
> do
> >> this:
> > It may seem surprising, that 2.0 is started before 1.0 is finally
> released.
> >
>
> hello dieter,
>
> soaplib development never stopped. i just created a branch before
> starting another overhaul, so that those who need a stable version
> sooner rather than later have something to work with. did you see the
> diff stat between 1_0 and master?
>
> $ git diff --stat 1_0 master
>  README.md                                   |   12 +-
>  doc/source/index.rst                        |    1 +
>  setup.cfg                                   |    2 +-
>  setup.py                                    |    2 +-
>  src/soaplib/__init__.py                     |   45 +--
>  src/soaplib/_base.py                        |  719
> +++++++++++++++++++++++++++
>  src/soaplib/mime.py                         |  290 +++++++++++
>  src/soaplib/serializers/base.py             |   24 +-
>  src/soaplib/serializers/clazz.py            |   13 +-
>  src/soaplib/serializers/enum.py             |    5 +-
>  src/soaplib/serializers/exception.py        |   22 +-
>  src/soaplib/serializers/primitive.py        |   15 +-
>  src/soaplib/service.py                      |  297 ++++++-----
>  src/soaplib/soap.py                         |  313 +-----------
>  src/soaplib/test/interop/server/_service.py |   17 +-
>  src/soaplib/test/interop/server/basic.py    |    2 +-
>  src/soaplib/test/interop/test_suds.py       |   14 +
>  src/soaplib/test/serializers/test_enum.py   |    5 +-
>  src/soaplib/test/test_soap.py               |    2 +-
>  src/soaplib/wsgi.py                         |  655
> +++----------------------
>  20 files changed, 1339 insertions(+), 1116 deletions(-)
>
> it touches almost the whole code base! the 1_0 branch did see some
> real-world testing, and i did not want to throw that all away. i
> explained why i can't stabilize soaplib-1.0 in another message.
>
> i have to work at my own pace. that's the best i can do for everybody
> else without distorting my own schedule.
>
> > This indicates a great deal of instability in the development process
> > (major versions are often associated with incompatible changes) --
> > not a good sign for the adoption of a package...
> >
> >
>
> i disagree. i think fast iteration is a positive sign.
>
> >> easy_install -U "soaplib<=1.0"
> > This will get soaplib at or before 1.0, but not e.g. "1.0p1" (patch 1).
> >
> > There is no fully reliably way to specify "latest (stable) 1.x release"
> --
> > a "setuptools" limitation. One might try something like "<=1.999999".
> >
> > The missing feature to easily restrict to stable versions with
> "easy_install"
> > causes some poeple to recommend to release only stable versions to
> "PyPI".
> > I have often got unstable versions with indeed have broken things for
> me...
> >
> >> in all honesty, i don't think that's a hurdle.
> > The slightly suboptimal version specification above, may show the
> > contrary ;-)
> >
> >
>
> those complaints belong to the setuptools issue tracker. you should know
> the limitations of your tools and take better care not to break your
> production.
>
> best regards,
> burak
>
>
>
>
> _______________________________________________
> 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/20101007/b5177962/attachment.html>

From bradallen137 at gmail.com  Thu Oct  7 17:56:53 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Thu, 7 Oct 2010 10:56:53 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <AANLkTinSNnSf9mPZ=LvnPUUSKgt_CGqHw0op+w=49LG_@mail.gmail.com>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
	<19629.41866.960960.664321@gargle.gargle.HOWL>
	<4CADAE93.4030105@arskom.com.tr>
	<AANLkTinSNnSf9mPZ=LvnPUUSKgt_CGqHw0op+w=49LG_@mail.gmail.com>
Message-ID: <AANLkTi=YZ0P5f3nvo3moQa+XSpWbmSh-iMEBr4H7Vphr@mail.gmail.com>

I would like to suggest that for soaplib, we follow the Semantic
Versioning rules laid out at semver.org.

Please see my responses below to various points in this thread.

On Thu, Oct 7, 2010 at 7:31 AM, Devin Venable <venable.devin at gmail.com> wrote:

> $apt-cache search soaplib
> python-soaplib - Python library for writing and calling soap web services
> The version in apt is 0.8. ?1.0 is not backwards compatible with 0.8, which
> was a problem for me and will be for others because when and if 1.0 ever
> makes it into the apt repository, those of us who have been using the
> library will see our code break. ?So backwards compatibility is really
> important and working out the versioning scheme is really important.

If we follow the semantic versioning rules, backward compatibility is
not protected between releases in 0.x branches. However, once a 1.x
version appears, backward compatibility is expected for that release
and should not break until the 2.x release. Backward compatibility is
tied the major release version.

Dieter wrote:
> This indicates a great deal of instability in the development process
> (major versions are often associated with incompatible changes) --
> not a good sign for the adoption of a package...

Burak responded:
> i disagree. i think fast iteration is a positive sign.

The fast iteration is great, Burak. However I would prefer it happen
in a topic branch, and should undergo some community code review
before merging into a branch destined for release. I can volunteer my
co-worker Chris Austin to help with the review process, and I hope
others in the community will volunteer to participate in the code
review process.

Brad wrote:
> Now that 1.0 and 2.0 have been released on PyPI, does that mean we
> can't go back in time and do-over?

Burak responded:
>sorry, what do you mean? i'm not familiar with this expression.

I'd like to re-version both the 1.x and the 2.x versions to be part of
the 0.9 series, in keeping with semantic versioning rules and
community expectations about the meanings of major release versions.

1.0 could become 0.9.4  (or maybe should not even have a release
version, just a branch name)
2.0 could become 0.9.5  (this branch would be the basis for heading toward 1.0)

PyPI should be pointed to the latest stable release. The 0.9.5 branch
would ultimately evolve toward becoming 1.0.

This might seem like a disruptive move and potentially create
confusion, but frankly I don't think soaplib is widely used yet. A
clear explanation on the PyPI page would likely prevent confusion, and
people who want to try out unstable versions could be directed to
Github.

Burak wrote:
>so anybody who wants to see a stable 1.0 release should start fixing
>those tests and send pull requests for the 1_0 branch my way. otherwise,
>i'm afraid soaplib 1.0 will be stuck in beta-limbo forever.

I don't see any benefit to continuing along that branch; does anyone
else? Is anybody using it at all? The approach taken in the 2.0 branch
addresses important separation of concerns.

I would like to suggest we define particular branches to be
"integration" branches, meaning that those are collaborative branches
destined for release. Those branches should go under continuous
integration, and topic branches should be reviewed before merging into
integration branches.

We should also adopt a policy of never merging to integration branches
unless tests are passing. This is not an onerous requirement; any
non-integration branches (usually called "topic branches") can be used
for work which involves temporarily breaking tests.

I am volunteering some resources to support this kind of process.
Where I work, soaplib is a critical dependency, and we'd like to
foster a community process leading toward greater robustness. By that
I mean, we want it to have a comprehensive feature set, elegant
testable design, strong standards adherence, and good interoperability
with other widely used SOAP implementations (.NET and Java).

We have several developers who can contribute. Chris Austin in
particular has recently started working on soaplib; he started with
updating the Sphinx documentation for the 1.0 beta, and since then has
been working on fixes to tests. He can help out with further
enhancements to soaplib going forward.

We're also thinking about creating soaplib jobs on our Hudson
continuous integration servers to run tests on specified branches of
soaplib whenever new codes appear. We can set up those jobs to email
the community if tests fail under Windows or Linux (though we don't
yet have any tests specific to .NET or Java right now).

If the community is in favor of this line of thinking, we can put
together a more detailed proposal of how the integration branches
could be organized, how the release process can be managed, etc.


From dieter at handshake.de  Thu Oct  7 20:21:24 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Thu, 7 Oct 2010 20:21:24 +0200
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CADAE93.4030105@arskom.com.tr>
References: <4CADAE93.4030105@arskom.com.tr>
Message-ID: <19630.4004.196614.993533@gargle.gargle.HOWL>

Burak Arslan wrote at 2010-10-7 14:27 +0300:
> On 10/07/10 13:40, Dieter Maurer wrote:
>> Burak Arslan wrote at 2010-10-7 11:27 +0300:
>>> ...
>>> so, 2.0 is alpha. i can't make it clearer that it's not ready for
>>> production yet. if you don't want to run my half-baked alpha software, do
>>> this:
>> It may seem surprising, that 2.0 is started before 1.0 is finally released.
>>
>
>hello dieter,
>
>soaplib development never stopped. i just created a branch before
>starting another overhaul, so that those who need a stable version
>sooner rather than later have something to work with. did you see the
>diff stat between 1_0 and master?

I am no "soaplib" user -- and read "soap at python.org" out of a general
interest in webservice support by Python.

My comments, therefore, are more general, not primarily related to
"soaplib".

"PyPI", per default, shows only the latest version of
a package. Therefore, it is probably that a novice user of a package
will see and use this latest version, even if it is not yet stable.
The maintainer can change this default behaviour. If he does, it
is less critical to register unstable versions (provided a stable version
is listed on "PyPI").

Users of a package likely want to profit from bug fixes. Therefore,
dependency specifications in the form ">= <some working version>" are
quite frequent. They often forget that newer versions may be unstable
or even completely incompatible. Those users will be happy, when
only stable (and if possible compatible) versions are only registered with
"PyPI".

> ...
>it touches almost the whole code base! the 1_0 branch did see some
>real-world testing, and i did not want to throw that all away. i
>explained why i can't stabilize soaplib-1.0 in another message.

I do not think that the original poster argues against you starting
work on a new "soaplib" generation. Due to peculiarities of "PyPI",
he probably has only reservations with respect to the "PyPI" registration.
Such a registration is probably only advicable when a large audience, far
beyond the developers and "pilot" users, might be interested in the version.
This strongly encourages only to register stable versions.

>i have to work at my own pace. that's the best i can do for everybody
>else without distorting my own schedule.
>
>> This indicates a great deal of instability in the development process
>> (major versions are often associated with incompatible changes) --
>> not a good sign for the adoption of a package...
>
>i disagree. i think fast iteration is a positive sign.

I am building large Zope applications which include hundreds of packages.
Therefore, I am happy when these packages have as few incompatible
changes (usually indicated by a change in the major version number)
as possible.

I have learned (by bad experience) that I must not trust package maintainers
that they use "PyPI" in a "general audience friendly" way.
I "fix" now the version to be included for each included package.

Nevertheless, I try to convince package maintainers to use
"PyPI" primarily to target the "general audience" and not "abuse" it
for "development purposes". Developers can easily access unstable code
from the code repositories and do not need "PyPI".

> ...
>those complaints belong to the setuptools issue tracker. you should know
>the limitations of your tools and take better care not to break your
>production.

I know them. But, you, too, are using "PyPI" and probably should
consider its typical use to avoid frustration with its other users...



--
Dieter


From burak.arslan at arskom.com.tr  Thu Oct  7 22:28:57 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Thu, 07 Oct 2010 23:28:57 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <19630.4004.196614.993533@gargle.gargle.HOWL>
References: <4CADAE93.4030105@arskom.com.tr>
	<19630.4004.196614.993533@gargle.gargle.HOWL>
Message-ID: <4CAE2D89.5030801@arskom.com.tr>


hi,

maybe i'm taking things too literally. here's what the lgpl says:

... PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.

so i could even transform soaplib to a library that just outputs random
breakfast recipes on import, and you can't blame me for what i did,
because you accepted lgpl by installing soaplib.

so i disagree with all those arguments about why i should care for lazy
users blindly installing the latest from pypi without running a diff
with what they already have and expect everything to work smoothly. the
one who installs that software should assume responsibility for his/her
actions, and can't blame anybody else if an update broke his/her setup.
that's there, in the contract between you and me, in capital letters, no
less.

but,

the soaplib entry in pypi is not my property -- it belongs to everybody.
i'm just doing a kind of a minor public service by deciding what goes
in. so i don't think i have the right to ignore what others say about
how i perform that work.

having seen the reactions to my pypi release policy so far, i will
delete 2.x from pypi, and won't put it back until there's a reasonable
agreement on its readiness for a wider audience.

any objections?

best regards,
burak



On 10/07/10 21:21, Dieter Maurer wrote:
> Burak Arslan wrote at 2010-10-7 14:27 +0300:
>> On 10/07/10 13:40, Dieter Maurer wrote:
>>> Burak Arslan wrote at 2010-10-7 11:27 +0300:
>>>> ...
>>>> so, 2.0 is alpha. i can't make it clearer that it's not ready for
>>>> production yet. if you don't want to run my half-baked alpha software, do
>>>> this:
>>> It may seem surprising, that 2.0 is started before 1.0 is finally released.
>>>
>> hello dieter,
>>
>> soaplib development never stopped. i just created a branch before
>> starting another overhaul, so that those who need a stable version
>> sooner rather than later have something to work with. did you see the
>> diff stat between 1_0 and master?
> I am no "soaplib" user -- and read "soap at python.org" out of a general
> interest in webservice support by Python.
>
> My comments, therefore, are more general, not primarily related to
> "soaplib".
>
> "PyPI", per default, shows only the latest version of
> a package. Therefore, it is probably that a novice user of a package
> will see and use this latest version, even if it is not yet stable.
> The maintainer can change this default behaviour. If he does, it
> is less critical to register unstable versions (provided a stable version
> is listed on "PyPI").
>
> Users of a package likely want to profit from bug fixes. Therefore,
> dependency specifications in the form ">= <some working version>" are
> quite frequent. They often forget that newer versions may be unstable
> or even completely incompatible. Those users will be happy, when
> only stable (and if possible compatible) versions are only registered with
> "PyPI".
>
>> ...
>> it touches almost the whole code base! the 1_0 branch did see some
>> real-world testing, and i did not want to throw that all away. i
>> explained why i can't stabilize soaplib-1.0 in another message.
> I do not think that the original poster argues against you starting
> work on a new "soaplib" generation. Due to peculiarities of "PyPI",
> he probably has only reservations with respect to the "PyPI" registration.
> Such a registration is probably only advicable when a large audience, far
> beyond the developers and "pilot" users, might be interested in the version.
> This strongly encourages only to register stable versions.
>
>> i have to work at my own pace. that's the best i can do for everybody
>> else without distorting my own schedule.
>>
>>> This indicates a great deal of instability in the development process
>>> (major versions are often associated with incompatible changes) --
>>> not a good sign for the adoption of a package...
>> i disagree. i think fast iteration is a positive sign.
> I am building large Zope applications which include hundreds of packages.
> Therefore, I am happy when these packages have as few incompatible
> changes (usually indicated by a change in the major version number)
> as possible.
>
> I have learned (by bad experience) that I must not trust package maintainers
> that they use "PyPI" in a "general audience friendly" way.
> I "fix" now the version to be included for each included package.
>
> Nevertheless, I try to convince package maintainers to use
> "PyPI" primarily to target the "general audience" and not "abuse" it
> for "development purposes". Developers can easily access unstable code
> from the code repositories and do not need "PyPI".
>
>> ...
>> those complaints belong to the setuptools issue tracker. you should know
>> the limitations of your tools and take better care not to break your
>> production.
> I know them. But, you, too, are using "PyPI" and probably should
> consider its typical use to avoid frustration with its other users...
>
>
>
> --
> Dieter



From venable.devin at gmail.com  Thu Oct  7 23:17:01 2010
From: venable.devin at gmail.com (Devin Venable)
Date: Thu, 7 Oct 2010 16:17:01 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CAE2D89.5030801@arskom.com.tr>
References: <4CADAE93.4030105@arskom.com.tr>
	<19630.4004.196614.993533@gargle.gargle.HOWL>
	<4CAE2D89.5030801@arskom.com.tr>
Message-ID: <AANLkTinqJoqQJ8qo8uqngGTMD+077LeTg5pk_y1SpzEo@mail.gmail.com>

Realizing that this isn't a democracy, I would still vote for Brad's
suggestions:

* re-version both the 1.x and the 2.x versions to be part of
the 0.9 series, in keeping with semantic versioning rules and
community expectations about the meanings of major release versions.

* 1.0 could become 0.9.4  (or maybe should not even have a release
version, just a branch name)

* 2.0 could become 0.9.5  (this branch would be the basis for heading toward
1.0)

* PyPI should be pointed to the latest stable release. The 0.9.5 branch
would ultimately evolve toward becoming 1.0.



On Thu, Oct 7, 2010 at 3:28 PM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>
> hi,
>
> maybe i'm taking things too literally. here's what the lgpl says:
>
> ... PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
> KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE.
>
> so i could even transform soaplib to a library that just outputs random
> breakfast recipes on import, and you can't blame me for what i did,
> because you accepted lgpl by installing soaplib.
>
> so i disagree with all those arguments about why i should care for lazy
> users blindly installing the latest from pypi without running a diff
> with what they already have and expect everything to work smoothly. the
> one who installs that software should assume responsibility for his/her
> actions, and can't blame anybody else if an update broke his/her setup.
> that's there, in the contract between you and me, in capital letters, no
> less.
>
> but,
>
> the soaplib entry in pypi is not my property -- it belongs to everybody.
> i'm just doing a kind of a minor public service by deciding what goes
> in. so i don't think i have the right to ignore what others say about
> how i perform that work.
>
> having seen the reactions to my pypi release policy so far, i will
> delete 2.x from pypi, and won't put it back until there's a reasonable
> agreement on its readiness for a wider audience.
>
> any objections?
>
> best regards,
> burak
>
>
>
> On 10/07/10 21:21, Dieter Maurer wrote:
> > Burak Arslan wrote at 2010-10-7 14:27 +0300:
> >> On 10/07/10 13:40, Dieter Maurer wrote:
> >>> Burak Arslan wrote at 2010-10-7 11:27 +0300:
> >>>> ...
> >>>> so, 2.0 is alpha. i can't make it clearer that it's not ready for
> >>>> production yet. if you don't want to run my half-baked alpha software,
> do
> >>>> this:
> >>> It may seem surprising, that 2.0 is started before 1.0 is finally
> released.
> >>>
> >> hello dieter,
> >>
> >> soaplib development never stopped. i just created a branch before
> >> starting another overhaul, so that those who need a stable version
> >> sooner rather than later have something to work with. did you see the
> >> diff stat between 1_0 and master?
> > I am no "soaplib" user -- and read "soap at python.org" out of a general
> > interest in webservice support by Python.
> >
> > My comments, therefore, are more general, not primarily related to
> > "soaplib".
> >
> > "PyPI", per default, shows only the latest version of
> > a package. Therefore, it is probably that a novice user of a package
> > will see and use this latest version, even if it is not yet stable.
> > The maintainer can change this default behaviour. If he does, it
> > is less critical to register unstable versions (provided a stable version
> > is listed on "PyPI").
> >
> > Users of a package likely want to profit from bug fixes. Therefore,
> > dependency specifications in the form ">= <some working version>" are
> > quite frequent. They often forget that newer versions may be unstable
> > or even completely incompatible. Those users will be happy, when
> > only stable (and if possible compatible) versions are only registered
> with
> > "PyPI".
> >
> >> ...
> >> it touches almost the whole code base! the 1_0 branch did see some
> >> real-world testing, and i did not want to throw that all away. i
> >> explained why i can't stabilize soaplib-1.0 in another message.
> > I do not think that the original poster argues against you starting
> > work on a new "soaplib" generation. Due to peculiarities of "PyPI",
> > he probably has only reservations with respect to the "PyPI"
> registration.
> > Such a registration is probably only advicable when a large audience, far
> > beyond the developers and "pilot" users, might be interested in the
> version.
> > This strongly encourages only to register stable versions.
> >
> >> i have to work at my own pace. that's the best i can do for everybody
> >> else without distorting my own schedule.
> >>
> >>> This indicates a great deal of instability in the development process
> >>> (major versions are often associated with incompatible changes) --
> >>> not a good sign for the adoption of a package...
> >> i disagree. i think fast iteration is a positive sign.
> > I am building large Zope applications which include hundreds of packages.
> > Therefore, I am happy when these packages have as few incompatible
> > changes (usually indicated by a change in the major version number)
> > as possible.
> >
> > I have learned (by bad experience) that I must not trust package
> maintainers
> > that they use "PyPI" in a "general audience friendly" way.
> > I "fix" now the version to be included for each included package.
> >
> > Nevertheless, I try to convince package maintainers to use
> > "PyPI" primarily to target the "general audience" and not "abuse" it
> > for "development purposes". Developers can easily access unstable code
> > from the code repositories and do not need "PyPI".
> >
> >> ...
> >> those complaints belong to the setuptools issue tracker. you should know
> >> the limitations of your tools and take better care not to break your
> >> production.
> > I know them. But, you, too, are using "PyPI" and probably should
> > consider its typical use to avoid frustration with its other users...
> >
> >
> >
> > --
> > Dieter
>
> _______________________________________________
> 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/20101007/521fb7cb/attachment.html>

From dieter at handshake.de  Fri Oct  8 09:41:47 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Fri, 8 Oct 2010 09:41:47 +0200
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CAE2D89.5030801@arskom.com.tr>
References: <4CAE2D89.5030801@arskom.com.tr>
Message-ID: <19630.52027.710368.816465@gargle.gargle.HOWL>

Burak Arslan wrote at 2010-10-7 23:28 +0300:
>maybe i'm taking things too literally. here's what the lgpl says:
>
>... PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
>KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
>IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>PURPOSE.
>
>so i could even transform soaplib to a library that just outputs random
>breakfast recipes on import, and you can't blame me for what i did,
>because you accepted lgpl by installing soaplib.

You could but, of course, it would make the package useless.

Not using a good release practise, too, makes the package less useful
than it can be.

>so i disagree with all those arguments about why i should care for lazy
>users blindly installing the latest from pypi without running a diff
>with what they already have and expect everything to work smoothly.

In my applications, there are hundreds of packages -- and I am really happy
when the maintainers follow a good release practice (which do not
force me to look at details such as diffs for each upgrade).

I am aware that I have no right to blame them when they do not --
but I choose the packages I use with good release practice
being an important aspect.

I have recently published server side SOAP/WSDL support for Zope, based
on "suds". The current discussion makes me happy that I have chosen
"suds" and not "soaplib" (even though my primary reasoning for the
choice turned out to be wrong: I have thought "suds"
(in contrast to "soaplib") would support SOAP 1.1 and 1.2, but
"suds", too, does not support SOAP 1.2).


>the
>one who installs that software should assume responsibility for his/her
>actions, and can't blame anybody else if an update broke his/her setup.

This is a rather narrow argumentation -- valid for small applications only.

As an example, the package mentioned above has a "suds" dependancy.
To be as usable as possible, it uses a loose dependancy specification
in the form "suds >= ...". Fixing the "suds" version would mean, that
people using the package are very restricted in the "suds" version they
can install.
Of course, the loose specification requires that the "suds" maintainer
does not publish unstable versions on "PyPI"...
If he does, someone installing my package would install something
potentially unworkable...

In addition: most package users would be unable to understand
the true meaning of diffs (or other details). How should they decide
whether a given change would cause problems in their package use?
I think of myself as a good developer. Nevertheless, I do not think
I would be able to determine from "suds" diffs whether or not a given
"suds" version would work with my package.
A good documentation and a good release practice must help me.

Fortunately, the "suds" documentation seems to indicate that
the author has a strong commitment to version compatibility.
A very strong point when I think about its use in my packages.

>that's there, in the contract between you and me, in capital letters, no
>less.

Surely, "suds", too, has such a legal statement in its contract --
as has any open source package I know.

Fortunately, most authors seem to have more ambitions and do
not want to limit themselves to the minimal extent of the "contract".
Otherwise, open source would be useless....

>but,
>
>the soaplib entry in pypi is not my property -- it belongs to everybody.
>i'm just doing a kind of a minor public service by deciding what goes
>in. so i don't think i have the right to ignore what others say about
>how i perform that work.
>
>having seen the reactions to my pypi release policy so far, i will
>delete 2.x from pypi, and won't put it back until there's a reasonable
>agreement on its readiness for a wider audience.
>
>any objections?

I am fine with this offer :-)



--
Dieter


From burak.arslan at arskom.com.tr  Fri Oct  8 09:43:47 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 08 Oct 2010 10:43:47 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <AANLkTi=YZ0P5f3nvo3moQa+XSpWbmSh-iMEBr4H7Vphr@mail.gmail.com>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>	<19629.41866.960960.664321@gargle.gargle.HOWL>	<4CADAE93.4030105@arskom.com.tr>	<AANLkTinSNnSf9mPZ=LvnPUUSKgt_CGqHw0op+w=49LG_@mail.gmail.com>
	<AANLkTi=YZ0P5f3nvo3moQa+XSpWbmSh-iMEBr4H7Vphr@mail.gmail.com>
Message-ID: <4CAECBB3.90201@arskom.com.tr>

 hello,

On 10/07/10 18:56, Brad Allen wrote:
> I would like to suggest that for soaplib, we follow the Semantic
> Versioning rules laid out at semver.org.
>

we already do, no? i will (and do) increment major version every time i
break backwards compatibility.

> The fast iteration is great, Burak. However I would prefer it happen
> in a topic branch, and should undergo some community code review
> before merging into a branch destined for release. I can volunteer my
> co-worker Chris Austin to help with the review process, and I hope
> others in the community will volunteer to participate in the code
> review process. 

that's overkill for a tiny project like soaplib. i'm not going to waste
time juggling all that.

we have the master branch, stable branches and tags. we'll iteratively
review changes to master, addressing concerns raised in reviews in later
commits. once the master is mature enough, it's copied to a new stable
branch, or cherry-pick'd to an existing one. once there are enough
changes that went into stable branches, we tag it and release.
 

> Brad wrote:
>> Now that 1.0 and 2.0 have been released on PyPI, does that mean we
>> can't go back in time and do-over?
> Burak responded:
>> sorry, what do you mean? i'm not familiar with this expression.
> I'd like to re-version both the 1.x and the 2.x versions to be part of
> the 0.9 series, in keeping with semantic versioning rules and
> community expectations about the meanings of major release versions.
>
> 1.0 could become 0.9.4  (or maybe should not even have a release
> version, just a branch name)
> 2.0 could become 0.9.5  (this branch would be the basis for heading toward 1.0)
>
> PyPI should be pointed to the latest stable release. The 0.9.5 branch
> would ultimately evolve toward becoming 1.0.
>
> This might seem like a disruptive move and potentially create
> confusion, but frankly I don't think soaplib is widely used yet. A
> clear explanation on the PyPI page would likely prevent confusion, and
> people who want to try out unstable versions could be directed to
> Github.
>

i'll need more than your frank belief about soaplib's usage to base such
a disruptive and confusing move on. also, my frank belief doesn't agree.
e.g. there are already django integration recipes for soaplib 1.0.



> Burak wrote:
>> so anybody who wants to see a stable 1.0 release should start fixing
>> those tests and send pull requests for the 1_0 branch my way. otherwise,
>> i'm afraid soaplib 1.0 will be stuck in beta-limbo forever.
> I don't see any benefit to continuing along that branch;

neither do i. but, there may be others who just need a soap server and
are happy with what soaplib-1.0 has to offer.

>  does anyone
> else? Is anybody using it at all? The approach taken in the 2.0 branch
> addresses important separation of concerns.

thanks!

> I would like to suggest we define particular branches to be
> "integration" branches, meaning that those are collaborative branches
> destined for release. Those branches should go under continuous
> integration, and topic branches should be reviewed before merging into
> integration branches.
>
> We should also adopt a policy of never merging to integration branches
> unless tests are passing. This is not an onerous requirement; any
> non-integration branches (usually called "topic branches") can be used
> for work which involves temporarily breaking tests.
>
> I am volunteering some resources to support this kind of process.
> Where I work, soaplib is a critical dependency, and we'd like to
> foster a community process leading toward greater robustness. By that
> I mean, we want it to have a comprehensive feature set, elegant
> testable design, strong standards adherence, and good interoperability
> with other widely used SOAP implementations (.NET and Java).
>
> We have several developers who can contribute. Chris Austin in
> particular has recently started working on soaplib; he started with
> updating the Sphinx documentation for the 1.0 beta, and since then has
> been working on fixes to tests. He can help out with further
> enhancements to soaplib going forward.
>
> We're also thinking about creating soaplib jobs on our Hudson
> continuous integration servers to run tests on specified branches of
> soaplib whenever new codes appear. We can set up those jobs to email
> the community if tests fail under Windows or Linux (though we don't
> yet have any tests specific to .NET or Java right now).
>
> If the community is in favor of this line of thinking, we can put
> together a more detailed proposal of how the integration branches
> could be organized, how the release process can be managed, etc.

just send the .net and java interop tests my way when you finish them.

best,
burak




From burak.arslan at arskom.com.tr  Fri Oct  8 11:29:06 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 08 Oct 2010 12:29:06 +0300
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <19630.52027.710368.816465@gargle.gargle.HOWL>
References: <4CAE2D89.5030801@arskom.com.tr>
	<19630.52027.710368.816465@gargle.gargle.HOWL>
Message-ID: <4CAEE462.5040502@arskom.com.tr>

 On 10/08/10 10:41, Dieter Maurer wrote:
> I have recently published server side SOAP/WSDL support for Zope, based
> on "suds". The current discussion makes me happy that I have chosen
> "suds" and not "soaplib" (even though my primary reasoning for the
> choice turned out to be wrong: I have thought "suds"
> (in contrast to "soaplib") would support SOAP 1.1 and 1.2, but
> "suds", too, does not support SOAP 1.2).
>

please comment here about how you expect newest soap standard to be
supported: http://github.com/arskom/soaplib/issues#issue/18


>> the
>> one who installs that software should assume responsibility for his/her
>> actions, and can't blame anybody else if an update broke his/her setup.
> This is a rather narrow argumentation -- valid for small applications only.
>

if your application is so large that you can't review every open-source
component it depends on, you should either:

1) accept the risk and be ready to handle unexpected breakages, and not
whine when it happens.

2) or pay the developers so that they start caring about not breaking
your system.

your kind of whining is a popular way to pressure open-source developers
to do more and more free (as in beer) work. their crime was just being
nice (naive?) enough put the work of their body and soul out for
everyone to benefit from.

i will not accept this mentality. i'm doing this because it's fun.
supporting whiners' setups is not my kind of fun. you can either join
the fun by supporting your own setup, (i.e. providing compatibility
layers and whatnot) or fork soaplib for all i care.


> Fortunately, the "suds" documentation seems to indicate that
> the author has a strong commitment to version compatibility.
> A very strong point when I think about its use in my packages.
>

i don't think it's fair to compare soaplib and suds. suds was designed,
from day one, for generality. it was designed with the whole soap spec
in mind. the author went so far to implement his own xml engine just to
be able to offer a proper pure-python solution.

soaplib was a quick hack people with other responsibilities came up with
when they needed a soap compatibility layer. api changes are inevitable
in this setup. if you can do better, do it. i'd love to have somebody
else do the work i have to do.

and if you used suds and not soaplib to solve your issues, why should i
have a problem with that? we're not competitors or anything, right? i
also think suds is a great library and use it whenever i can.

so, all this boils down to this: you don't like something in soaplib?
patches are welcome.

best regards,
burak





From bradallen137 at gmail.com  Fri Oct  8 14:58:31 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 8 Oct 2010 07:58:31 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <19630.52027.710368.816465@gargle.gargle.HOWL>
References: <4CAE2D89.5030801@arskom.com.tr>
	<19630.52027.710368.816465@gargle.gargle.HOWL>
Message-ID: <AANLkTikh33qt_i9rzsZfm0iRg3sHz2uZmuh3DEezRvZe@mail.gmail.com>

On Fri, Oct 8, 2010 at 2:41 AM, Dieter Maurer <dieter at handshake.de> wrote:

> I have recently published server side SOAP/WSDL support for Zope, based
> on "suds".

Thanks for pointing that out; I didn't know about it. Googling for
"Zope suds" I found this:

    http://pypi.python.org/pypi/dm.zope.rpc.wsdl_suds/0.2a1

"suds is slightly abused by using it to implement a server component".
This makes me wonder if server side suds is in the future planning of
that package.

Btw, it is also possible to use soaplib as a server within Zope 2; we
are currently doing that with soaplib 0.8 and Zope 2.12.

> The current discussion makes me happy that I have chosen
> "suds" and not "soaplib"

Once we can settle our community process issues, I hope you'll take
another look at soaplib. It has a lot to offer as a server side
solution in terms of performance (lxml-based), and the API for
declaring WSDL is very nice. The current work is also leading toward
architectural improvements (separation of server from SOAP aspects and
more testable design), and very soon we'll have a nice Sphinx site
with full documentation.

> (even though my primary reasoning for the
> choice turned out to be wrong: I have thought "suds"
> (in contrast to "soaplib") would support SOAP 1.1 and 1.2, but
> "suds", too, does not support SOAP 1.2).

We'd also like to be able to support SOAP 1.2, thought I'm not yet
clear on the level of effort required to implement that for soaplib.


From dieter at handshake.de  Fri Oct  8 18:21:10 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Fri, 8 Oct 2010 18:21:10 +0200
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <AANLkTikh33qt_i9rzsZfm0iRg3sHz2uZmuh3DEezRvZe@mail.gmail.com>
References: <4CAE2D89.5030801@arskom.com.tr>
	<19630.52027.710368.816465@gargle.gargle.HOWL>
	<AANLkTikh33qt_i9rzsZfm0iRg3sHz2uZmuh3DEezRvZe@mail.gmail.com>
Message-ID: <19631.17654.330004.659958@gargle.gargle.HOWL>

Brad Allen wrote at 2010-10-8 07:58 -0500:
>On Fri, Oct 8, 2010 at 2:41 AM, Dieter Maurer <dieter at handshake.de> wrote:
>
>> I have recently published server side SOAP/WSDL support for Zope, based
>> on "suds".
>
>Thanks for pointing that out; I didn't know about it. Googling for
>"Zope suds" I found this:
>
>    http://pypi.python.org/pypi/dm.zope.rpc.wsdl_suds/0.2a1
>
>"suds is slightly abused by using it to implement a server component".
>This makes me wonder if server side suds is in the future planning of
>that package.

I do not know. I have not communicated with the "suds" author.

It has not been difficult to use "suds" for server side tasks.
Thus, if the author would like to support such use, he should not have
big problems.

>Btw, it is also possible to use soaplib as a server within Zope 2; we
>are currently doing that with soaplib 0.8 and Zope 2.12.

This answers your question -- as you already do it.

It should also not be difficult to implement a wsdl plugin for
"dm.zope.rpc" based on "soaplib". I probably won't do it as
I am quite happy with the "suds" integration.
I use "suds" also for client side wsdl and prefer to use fewer packages
than more of them (to limit the number of potential surprises in case
of updates).
>
>> The current discussion makes me happy that I have chosen
>> "suds" and not "soaplib"
>
>Once we can settle our community process issues, I hope you'll take
>another look at soaplib. It has a lot to offer as a server side
>solution in terms of performance (lxml-based), and the API for
>declaring WSDL is very nice. The current work is also leading toward
>architectural improvements (separation of server from SOAP aspects and
>more testable design), and very soon we'll have a nice Sphinx site
>with full documentation.

I do not doubt that "soaplib" has nice features. But I am quite lazy
and do things only, if there is real need. This means that
I will only have a deep look at "soaplib", should I face serious
problems I cannot solve with the solution I have now...



--
Dieter


From dieter at handshake.de  Fri Oct  8 18:33:09 2010
From: dieter at handshake.de (Dieter Maurer)
Date: Fri, 8 Oct 2010 18:33:09 +0200
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CAEE462.5040502@arskom.com.tr>
References: <4CAEE462.5040502@arskom.com.tr>
Message-ID: <19631.18373.713564.675848@gargle.gargle.HOWL>

Burak Arslan wrote at 2010-10-8 12:29 +0300:
> ...
>> This is a rather narrow argumentation -- valid for small applications only.
>>
>
>if your application is so large that you can't review every open-source
>component it depends on, you should either:
>
>1) accept the risk and be ready to handle unexpected breakages, and not
>whine when it happens.
>
>2) or pay the developers so that they start caring about not breaking
>your system.
>
>your kind of whining is a popular way to pressure open-source developers
>to do more and more free (as in beer) work. their crime was just being
>nice (naive?) enough put the work of their body and soul out for
>everyone to benefit from.

I am not whining. I am explaining what aspects are important for me
to chose a package -- and that I am happy, I have not chosen "soaplib".

And I am not only using open source software but I produce and support
it as well. My quality criteria are very different from yours: compatibility
between versions is one of my major aims -- maybe, because I know
the problems incompatibilities can cause.

>i will not accept this mentality. i'm doing this because it's fun.

Fine. I will forget about "soaplib"....



--
Dieter


From bradallen137 at gmail.com  Fri Oct  8 18:55:29 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 8 Oct 2010 11:55:29 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CAECBB3.90201@arskom.com.tr>
References: <50757.86.108.222.113.1286440068.squirrel@mail.in.arskom.com.tr>
	<19629.41866.960960.664321@gargle.gargle.HOWL>
	<4CADAE93.4030105@arskom.com.tr>
	<AANLkTinSNnSf9mPZ=LvnPUUSKgt_CGqHw0op+w=49LG_@mail.gmail.com>
	<AANLkTi=YZ0P5f3nvo3moQa+XSpWbmSh-iMEBr4H7Vphr@mail.gmail.com>
	<4CAECBB3.90201@arskom.com.tr>
Message-ID: <AANLkTinr7F1KA1H07BysezKn5fug7zM2_BTA6K_hG=VB@mail.gmail.com>

On Fri, Oct 8, 2010 at 2:43 AM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
> ?hello,
>
> On 10/07/10 18:56, Brad Allen wrote:
>> I would like to suggest that for soaplib, we follow the Semantic
>> Versioning rules laid out at semver.org.
>>
>
> we already do, no? i will (and do) increment major version every time i
> break backwards compatibility.

Right, but semantic versioning rules also reserve the 0.x series for
complete freedom to break backward compatibility. Given that soaplib
is still in a state of flux, I think keeping within the 0.x range
would be in line with community expectations.

>> The fast iteration is great, Burak. However I would prefer it happen
>> in a topic branch, and should undergo some community code review
>> before merging into a branch destined for release. I can volunteer my
>> co-worker Chris Austin to help with the review process, and I hope
>> others in the community will volunteer to participate in the code
>> review process.
>
> that's overkill for a tiny project like soaplib. i'm not going to waste
> time juggling all that.

I thought you were finding feedback helpful. I know you and Chris have
had a lot of off-list discussion about recent changes.

Besides, soaplib is far from a "tiny" project; it's not trivial in the
least. Code review is a highly beneficial process; it's not about
getting in your way with a cumbersome process. It's about getting
another set of interested eyes on the code and having a dialog.

The use of topic branches is also far from cumbersome, especially with
the way Git makes merging so painless.


From bradallen137 at gmail.com  Fri Oct  8 19:26:39 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 8 Oct 2010 12:26:39 -0500
Subject: [Soap-Python] soaplib versioning and community process
In-Reply-To: <4CAEE462.5040502@arskom.com.tr>
References: <4CAE2D89.5030801@arskom.com.tr>
	<19630.52027.710368.816465@gargle.gargle.HOWL>
	<4CAEE462.5040502@arskom.com.tr>
Message-ID: <AANLkTimoT5G9pHLvxaHr8KpPKSZM1v9x++RQVwQY8hsN@mail.gmail.com>

On Fri, Oct 8, 2010 at 4:29 AM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
>>> one who installs that software should assume responsibility for his/her
>>> actions, and can't blame anybody else if an update broke his/her setup.
>> This is a rather narrow argumentation -- valid for small applications only.
>>
>
> if your application is so large that you can't review every open-source
> component it depends on, you should either:
>
> 1) accept the risk and be ready to handle unexpected breakages, and not
> whine when it happens.
>
> 2) or pay the developers so that they start caring about not breaking
> your system.
>
> your kind of whining is a popular way to pressure open-source developers
> to do more and more free (as in beer) work. their crime was just being
> nice (naive?) enough put the work of their body and soul out for
> everyone to benefit from.
>
> i will not accept this mentality. i'm doing this because it's fun.
> supporting whiners' setups is not my kind of fun. you can either join
> the fun by supporting your own setup, (i.e. providing compatibility
> layers and whatnot) or fork soaplib for all i care.

C'mon...as he pointed out Dieter is not whining; his feedback is
valuable and based on a lot of Python community experience.

You know it's possible to both have fun and be a professional too. The
Python community is full of professional developers who program for
fun and use open source software as part of their job. I know that's
why I'm here instead of working in a .NET shop.

I'd prefer to avoid forking the project if possible. Your code
contributions to soaplib have been awesome; we want to be on your
team. But in order for other developers to jump on the merry-go-round,
it would help to have some defined processes in place. I'm not asking
for bureaucracy, just some planning, code review, and the release
process should take into the accounts of the interests of other
soaplib users.

Personally, I like the idea of a time-based release process, with
rotating release managers. I've heard about this on some of the bigger
open source projects (like Rakudo Perl 6); that might be overkill for
soaplib. However, those of us who do want to see more structure around
the release process could volunteer for that kind of work. That would
leave you, Burak, off the hook for managing releases and you could
focus on the part you enjoy.

Btw, I think earlier in this thread you did agree in principle to the
semantic versioning approach, which should address the concerns about
API volatility and backward compatibility. So maybe we're in agreement
on the overall approach, and we don't really have anything to argue
about in that case.


From harsha.mukkera at gmail.com  Wed Oct 13 02:23:42 2010
From: harsha.mukkera at gmail.com (mukkera harsha)
Date: Tue, 12 Oct 2010 20:23:42 -0400
Subject: [Soap-Python] AnyAsDict(String)
Message-ID: <AANLkTimdKOPE1ZiciotLRjzbo2G=E6qbmYOr+9ohgFfq@mail.gmail.com>

Hi,

I am getting the following errror :

Traceback (most recent call last):
File "workflowexecutionservice.py", line 24, in

class Subworkflow(ClassSerializer):

File "workflowexecutionservice.py", line 26, in Subworkflow

files = AnyAsDict(String)

TypeError: *new*() takes exactly 1 argument (2 given)

-------------

I attached is the source code. Please help me to get through this problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101012/2109815f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workflowexecutionservice.py
Type: application/octet-stream
Size: 5597 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/soap/attachments/20101012/2109815f/attachment.obj>

From burak.arslan at arskom.com.tr  Wed Oct 13 14:51:00 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Wed, 13 Oct 2010 15:51:00 +0300
Subject: [Soap-Python] AnyAsDict(String)
In-Reply-To: <AANLkTimdKOPE1ZiciotLRjzbo2G=E6qbmYOr+9ohgFfq@mail.gmail.com>
References: <AANLkTimdKOPE1ZiciotLRjzbo2G=E6qbmYOr+9ohgFfq@mail.gmail.com>
Message-ID: <4CB5AB34.1090001@arskom.com.tr>

 On 10/13/10 03:23, mukkera harsha wrote:
> Hi,
>
> I am getting the following errror :
>
> Traceback (most recent call last):
> File "workflowexecutionservice.py", line 24, in
>
> |class Subworkflow(ClassSerializer):
> |
>
> File "workflowexecutionservice.py", line 26, in Subworkflow
>
> |files = AnyAsDict(String) 
> |
>
> TypeError: *new*() takes exactly 1 argument (2 given)
>
> -------------
>
> I attached is the source code. Please help me to get through this problem.
>
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap


hi,

AnyAsDict(String) does not make sense. just use AnyAsDict.

You also should return a dictionary whose values are inside iterables.

not like:

{'return_key': 'return value'}

but like:

{'return_key': ['return_value']}

hope that helps
burak



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101013/44b3aadd/attachment.html>

From burak.arslan at arskom.com.tr  Wed Oct 13 17:15:25 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Wed, 13 Oct 2010 18:15:25 +0300
Subject: [Soap-Python] AnyAsDict(String)
In-Reply-To: <AANLkTikRxJ+3iWDoeP0K+KbxpxOdrvuiUztqpLFyCMCg@mail.gmail.com>
References: <AANLkTimdKOPE1ZiciotLRjzbo2G=E6qbmYOr+9ohgFfq@mail.gmail.com>	<4CB5AB34.1090001@arskom.com.tr>
	<AANLkTikRxJ+3iWDoeP0K+KbxpxOdrvuiUztqpLFyCMCg@mail.gmail.com>
Message-ID: <4CB5CD0D.8060807@arskom.com.tr>

 On 10/13/10 17:15, mukkera harsha wrote:
> But, we are converting an XMl file into a dictionary. So where should
> we tell that so and so XML file should be converted into dictionary .
> Where should we give the filename ?
>

read the file and convert it to xml and later to dict if you want:

xml_string = open('myfile.xml', 'r').read()
xml_etree = etree.fromstring(xml_string)
xml_dict = soaplib.util.etreeconv.rroot_etree_to_dict(xml_etree)

or use the attachment serializer.

http://github.com/arskom/soaplib/blob/1_0/src/soaplib/serializers/binary.py

burak


> On Wed, Oct 13, 2010 at 8:51 AM, Burak Arslan
> <burak.arslan at arskom.com.tr <mailto:burak.arslan at arskom.com.tr>> wrote:
>
>     On 10/13/10 03:23, mukkera harsha wrote:
>>     Hi,
>>
>>     I am getting the following errror :
>>
>>     Traceback (most recent call last):
>>     File "workflowexecutionservice.py", line 24, in
>>
>>     |class Subworkflow(ClassSerializer):
>>     |
>>
>>     File "workflowexecutionservice.py", line 26, in Subworkflow
>>
>>     |files = AnyAsDict(String) 
>>     |
>>
>>     TypeError: *new*() takes exactly 1 argument (2 given)
>>
>>     -------------
>>
>>     I attached is the source code. Please help me to get through this
>>     problem.
>>
>>
>>     _______________________________________________
>>     Soap mailing list
>>     Soap at python.org <mailto:Soap at python.org>
>>     http://mail.python.org/mailman/listinfo/soap
>
>
>     hi,
>
>     AnyAsDict(String) does not make sense. just use AnyAsDict.
>
>     You also should return a dictionary whose values are inside iterables.
>
>     not like:
>
>     {'return_key': 'return value'}
>
>     but like:
>
>     {'return_key': ['return_value']}
>
>     hope that helps
>     burak
>
>
>
>
>
>
> -- 
> Harshavardhan Reddy Mukkera.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101013/d08fff4d/attachment.html>

From burak.arslan at arskom.com.tr  Wed Oct 13 22:59:42 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Wed, 13 Oct 2010 23:59:42 +0300
Subject: [Soap-Python] the new soap client in soaplib
Message-ID: <4CB61DBE.1050507@arskom.com.tr>


hello,

since the forking of 1_0 branch, i've been working on transforming
soaplib to a general soap processing library.

in order to see how the new api fared, i thought it would be a good idea
to reimplement the soaplib soap client that used http as transport. this
exercise did help fixing a lot of rough edges, but i feel there's still
a lot of work to be done.

i will next work on using other transports in order to better modularize
the api.

as of the latest release (that i have not released on pypi, but is
available from soaplib download page) the soaplib http soap client
passes most of the interop tests. (and that's in just ~100 lines) while
it's significantly faster than suds, it's not supported, nor much usable
against (imo), any other soap server than soaplib as it doesn't do any
wsdl parsing whatsoever.

while implementing the client, i tried to imitate the suds api as best
as i could. there are differences of course, especially with array
handling. you can compare test_client.py and test_suds.py to see this
for yourself.

running suds tests:

   py.test -v test_suds.py

results in:  3 failed, 13 passed in 2.50 seconds.

whereas running the soaplib client tests:

   py.test -v test_client.py

results in: 3 failed, 13 passed in 0.29 seconds

you need to be running the basic interop server to be able to run the tests.

yours,
burak




From burak.arslan at arskom.com.tr  Fri Oct 15 10:34:03 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 15 Oct 2010 11:34:03 +0300
Subject: [Soap-Python] soaplib versioning and community process (conclusions)
Message-ID: <4CB811FB.7060600@arskom.com.tr>


all,

you might remember the recent heated discussion about how soaplib
releases get handled. i wanted to summarize the conclusions that we came
to, in order not to leave the thread hanging.

1) chris austin from brad's team has full access to the soaplib repo.

2) development will happen in personal forks. the new features will get
merged to the main repo once completed.

brad's idea of *_dev branches are not needed thanks to the code review
features of github.

3) there will be no change in the soaplib versions.

there are disagreements over whether the soaplib-1.0 release is mature
and stable enough for a 1.0 release. however, we all agree that changing
the version numbers of already-released packages would be a very
confusing move. as i did not want to do such a thing without good
reason, we are keeping the version numbers as they are.

4) soaplib-2.0 won't hit pypi until there's reasonable consensus on its
readiness for a wider audience.

5) i have been respecting, and will respect, semantic versioning rules,
outlined at semver.org. this means we keep backwards compatibility on
major versions. (e.g. 2.0.x code will run unmodified on 2.1, but 3.0 may
or may not break some (or all) compatibility with 2.x)

and it will be a more committee-like decision process from now on.

6) on a more personal note, i won't provide compatibility layers between
incompatible versions, and will remind you the relevant parts of the
lgpl if you keep on complaining.

oh but, we will certainly review them for inclusion to the point-oh
releases if a decent contribution comes our way.

it's also false to assume that if so-and-so distro has this-and-that
package in its repo, it must be stable and ready for production use.
(e.g. soaplib-0.8.1 had epic bugs regarding compatibility) always use
the latest package from pypi (with keeping an eye on major versions and
alpha-beta tags) and don't rely solely on what distros offer. and i'm
not saying this to belittle the work those folks do, it's just that they
can never judge the stability of a package better than the package's author.

anybody with anything to add?

yours,
burak





From burak.arslan at arskom.com.tr  Fri Oct 15 10:40:37 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 15 Oct 2010 11:40:37 +0300
Subject: [Soap-Python] 0.8.2 stable release
Message-ID: <4CB81385.70105@arskom.com.tr>

 hi,

i plan to release soaplib 0.8.2 stable release in the coming days.

any objections?

burak



From bradallen137 at gmail.com  Fri Oct 15 18:34:36 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 15 Oct 2010 11:34:36 -0500
Subject: [Soap-Python] soaplib versioning and community process
	(conclusions)
In-Reply-To: <4CB811FB.7060600@arskom.com.tr>
References: <4CB811FB.7060600@arskom.com.tr>
Message-ID: <AANLkTik911t7m-k9dcTP2Q5nmtkRp4ABWCxQfQiRhFCu@mail.gmail.com>

That covers it pretty well, and I'm on board with this plan. Thanks
for summarizing, Burak.

Here are few more points from our off-list discussion:

* Anyone in the group of core committers has the capability of
performing a release, so that responsibility can rotate. Right now
there are only two core committers (Burak and Chris Austin), but that
group may grow depending on what kind of contributions appear. The
path to becoming a core committer is to make repeated good quality
pull requests on Github, and express an interest in joining the team.

* Code review is not done only by those with commit access. In some
cases newbies should be invited to do code review of a topic branch.
This could be a great onramp for new developers to get involved in
soaplib code. The specifics of how the code review process have yet to
be worked out but we'll get there.

* We'll be starting a public soaplib-bots mailing list to email the
results of continuous integration testing against any new changes to
the maintenance and master branches of soaplib (0.8, 1.0, and master,
with 2.0 to become a maintenance branch after the release). Hopefully
this will be up and running within a week or two using my employer's
Hudson server. If anyone else wants to help out with setting up
continuous integration jobs, they'll be welcome to dump test messages
onto the same mailing list.


On Fri, Oct 15, 2010 at 3:34 AM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:
>
> all,
>
> you might remember the recent heated discussion about how soaplib
> releases get handled. i wanted to summarize the conclusions that we came
> to, in order not to leave the thread hanging.
>
> 1) chris austin from brad's team has full access to the soaplib repo.
>
> 2) development will happen in personal forks. the new features will get
> merged to the main repo once completed.
>
> brad's idea of *_dev branches are not needed thanks to the code review
> features of github.
>
> 3) there will be no change in the soaplib versions.
>
> there are disagreements over whether the soaplib-1.0 release is mature
> and stable enough for a 1.0 release. however, we all agree that changing
> the version numbers of already-released packages would be a very
> confusing move. as i did not want to do such a thing without good
> reason, we are keeping the version numbers as they are.
>
> 4) soaplib-2.0 won't hit pypi until there's reasonable consensus on its
> readiness for a wider audience.
>
> 5) i have been respecting, and will respect, semantic versioning rules,
> outlined at semver.org. this means we keep backwards compatibility on
> major versions. (e.g. 2.0.x code will run unmodified on 2.1, but 3.0 may
> or may not break some (or all) compatibility with 2.x)
>
> and it will be a more committee-like decision process from now on.
>
> 6) on a more personal note, i won't provide compatibility layers between
> incompatible versions, and will remind you the relevant parts of the
> lgpl if you keep on complaining.
>
> oh but, we will certainly review them for inclusion to the point-oh
> releases if a decent contribution comes our way.
>
> it's also false to assume that if so-and-so distro has this-and-that
> package in its repo, it must be stable and ready for production use.
> (e.g. soaplib-0.8.1 had epic bugs regarding compatibility) always use
> the latest package from pypi (with keeping an eye on major versions and
> alpha-beta tags) and don't rely solely on what distros offer. and i'm
> not saying this to belittle the work those folks do, it's just that they
> can never judge the stability of a package better than the package's author.
>
> anybody with anything to add?
>
> yours,
> burak
>
>
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From harsha.mukkera at gmail.com  Fri Oct 15 20:18:32 2010
From: harsha.mukkera at gmail.com (mukkera harsha)
Date: Fri, 15 Oct 2010 14:18:32 -0400
Subject: [Soap-Python] soaplib - python help
Message-ID: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>

I am getting the following error.

Error ::
----------

    for k, v in files.iteritems():
AttributeError: type object 'AnyAsDict' has no attribute 'iteritems'

Code ::
------------

class Subworkflow(ClassSerializer):
        subworkflowid = String
        files = AnyAsDict
        for k, v in files.iteritems():
                base64.decode(v, open(k,"w"))


Here "Subworkflow" class is a tiny class that has two identifiers
subworkflowid and files.

I am NOT passing in raw arguments to your function, I am passing in an
actual Subworkflow object... that soaplib will have already automatically
constructed for me.


 [ I want to know , how Soaplib automatically handle the soap xml envelope
for you and automatically turn the argument into an object of type
Subworkflow( our class here ). ]


I know that I dint code it properly, But I am not getting any idea of how to
do that. I am a newbie.


Your help is greatly appreciated.

-- 
Harshavardhan Reddy Mukkera.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101015/5d329c77/attachment.html>

From ovnicraft at gmail.com  Fri Oct 15 21:40:17 2010
From: ovnicraft at gmail.com (Ovnicraft)
Date: Fri, 15 Oct 2010 14:40:17 -0500
Subject: [Soap-Python] soaplib versioning and community process
	(conclusions)
In-Reply-To: <4CB811FB.7060600@arskom.com.tr>
References: <4CB811FB.7060600@arskom.com.tr>
Message-ID: <AANLkTinZ4aBNoDC5PZh1ySu5Gc7pNrHX2rn5UgTna8ex@mail.gmail.com>

On Fri, Oct 15, 2010 at 3:34 AM, Burak Arslan <burak.arslan at arskom.com.tr>wrote:

>
> all,
>
> you might remember the recent heated discussion about how soaplib
> releases get handled. i wanted to summarize the conclusions that we came
> to, in order not to leave the thread hanging.
>
> 1) chris austin from brad's team has full access to the soaplib repo.
>
> 2) development will happen in personal forks. the new features will get
> merged to the main repo once completed.
>
> brad's idea of *_dev branches are not needed thanks to the code review
> features of github.
>
> 3) there will be no change in the soaplib versions.
>
> there are disagreements over whether the soaplib-1.0 release is mature
> and stable enough for a 1.0 release. however, we all agree that changing
> the version numbers of already-released packages would be a very
> confusing move. as i did not want to do such a thing without good
> reason, we are keeping the version numbers as they are.
>
> 4) soaplib-2.0 won't hit pypi until there's reasonable consensus on its
> readiness for a wider audience.
>
> 5) i have been respecting, and will respect, semantic versioning rules,
> outlined at semver.org. this means we keep backwards compatibility on
> major versions. (e.g. 2.0.x code will run unmodified on 2.1, but 3.0 may
> or may not break some (or all) compatibility with 2.x)
>
> and it will be a more committee-like decision process from now on.
>
> 6) on a more personal note, i won't provide compatibility layers between
> incompatible versions, and will remind you the relevant parts of the
> lgpl if you keep on complaining.
>
> oh but, we will certainly review them for inclusion to the point-oh
> releases if a decent contribution comes our way.
>
> it's also false to assume that if so-and-so distro has this-and-that
> package in its repo, it must be stable and ready for production use.
> (e.g. soaplib-0.8.1 had epic bugs regarding compatibility) always use
> the latest package from pypi (with keeping an eye on major versions and
> alpha-beta tags) and don't rely solely on what distros offer. and i'm
> not saying this to belittle the work those folks do, it's just that they
> can never judge the stability of a package better than the package's
> author.
>
> anybody with anything to add?
>
> yours,
> burak
>
>
I have a question, what time will realeased each? (minor, major)

Regards,

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



-- 
Cristian Salamea
@ovnicraft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101015/908ec44c/attachment.html>

From burak.arslan at arskom.com.tr  Sat Oct 16 12:35:32 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 16 Oct 2010 13:35:32 +0300
Subject: [Soap-Python] soaplib versioning and community process
	(conclusions)
In-Reply-To: <4CB811FB.7060600@arskom.com.tr>
References: <4CB811FB.7060600@arskom.com.tr>
Message-ID: <4CB97FF4.5050201@arskom.com.tr>

 On 10/15/10 11:34, Burak Arslan wrote:
> all,
>
> you might remember the recent heated discussion about how soaplib
> releases get handled. i wanted to summarize the conclusions that we came
> to, in order not to leave the thread hanging.
>
> 1) chris austin from brad's team has full access to the soaplib repo.
>
> 2) development will happen in personal forks. the new features will get
> merged to the main repo once completed.
>
> brad's idea of *_dev branches are not needed thanks to the code review
> features of github.
>
> 3) there will be no change in the soaplib versions.
>
> there are disagreements over whether the soaplib-1.0 release is mature
> and stable enough for a 1.0 release. however, we all agree that changing
> the version numbers of already-released packages would be a very
> confusing move. as i did not want to do such a thing without good
> reason, we are keeping the version numbers as they are.
>
> 4) soaplib-2.0 won't hit pypi until there's reasonable consensus on its
> readiness for a wider audience.
>
> 5) i have been respecting, and will respect, semantic versioning rules,
> outlined at semver.org. this means we keep backwards compatibility on
> major versions. (e.g. 2.0.x code will run unmodified on 2.1, but 3.0 may
> or may not break some (or all) compatibility with 2.x)
>
> and it will be a more committee-like decision process from now on.
>
> 6) on a more personal note, i won't provide compatibility layers between
> incompatible versions, and will remind you the relevant parts of the
> lgpl if you keep on complaining.
>
> oh but, we will certainly review them for inclusion to the point-oh
> releases if a decent contribution comes our way.
>
> it's also false to assume that if so-and-so distro has this-and-that
> package in its repo, it must be stable and ready for production use.
> (e.g. soaplib-0.8.1 had epic bugs regarding compatibility) always use
> the latest package from pypi (with keeping an eye on major versions and
> alpha-beta tags) and don't rely solely on what distros offer. and i'm
> not saying this to belittle the work those folks do, it's just that they
> can never judge the stability of a package better than the package's author.
>
> anybody with anything to add?

me!

when asking for help, please don't forget to specify the version of
soaplib you're working with. this will save both parties one email
round-trip time.

thanks!
burak

> yours,
> burak
>
>
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap



From burak.arslan at arskom.com.tr  Sat Oct 16 12:48:16 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 16 Oct 2010 13:48:16 +0300
Subject: [Soap-Python] soaplib - python help
In-Reply-To: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>
References: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>
Message-ID: <4CB982F0.4050002@arskom.com.tr>


okay, first, stop bombarding the mailing list with your question. once
is enough.

On 10/15/10 21:18, mukkera harsha wrote:
>
> I am getting the following error.
>
> Error ::
> ----------
>
>     for k, v in files.iteritems():
> AttributeError: type object 'AnyAsDict' has no attribute 'iteritems'
>
> Code ::
> ------------
>
> class Subworkflow(ClassSerializer):
>         subworkflowid = String
>         files = AnyAsDict
>         for k, v in files.iteritems():
>                 base64.decode(v, open(k,"w"))
>
>
> Here "Subworkflow" class is a tiny class that has two identifiers
> subworkflowid and files.
>
> I am NOT passing in raw arguments to your function, I am passing in an
> actual Subworkflow object... that soaplib will have already
> automatically constructed for me.
>
>

mukkera, i'm sorry but i do not have the faintest idea about what you're
trying to achieve. you are not passing anything to any function as far
as soaplib is concerned.


>  [ I want to know , how Soaplib automatically handle the soap xml
> envelope for you and automatically turn the argument into an object of
> type Subworkflow( our class here ). ]
>
>

while i don't think you really mean what you wrote, i'll still answer
you: we have a site for that. http://github.com/arskom/soaplib

have a look here:
http://github.com/arskom/soaplib/blob/master/src/soaplib/type/clazz.py#L177

> I know that I dint code it properly, But I am not getting any idea of
> how to do that. I am a newbie.
>
>

it looks like you're too much of a newbie for this forum. try a more
python-centric forum for newbies for your questions.

burak



From piet at vanoostrum.org  Sat Oct 16 13:50:22 2010
From: piet at vanoostrum.org (Piet van Oostrum)
Date: Sat, 16 Oct 2010 07:50:22 -0400
Subject: [Soap-Python] soaplib - python help
In-Reply-To: <4CB982F0.4050002@arskom.com.tr>
References: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>
	<4CB982F0.4050002@arskom.com.tr>
Message-ID: <19641.37246.671040.261251@cochabamba.vanoostrum.org>

On 10/15/10 21:18, mukkera harsha wrote:
 >
 > I am getting the following error.
 >
 > Error ::
 > ----------
 >
 >     for k, v in files.iteritems(): AttributeError: type object
 > 'AnyAsDict' has no attribute 'iteritems'
 >
 > Code ::
 > ------------
 >
 > class Subworkflow(ClassSerializer):
 >         subworkflowid = String
 >         files = AnyAsDict

At least these two line should probably be:
         subworkflowid = String()
         files = AnyAsDict()

-- 
Piet van Oostrum
Cochabamba. URL: http://pietvanoostrum.com/
Nu Fair Trade woonartikelen op http://www.zylja.com


From burak.arslan at arskom.com.tr  Sat Oct 16 15:09:57 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 16 Oct 2010 16:09:57 +0300
Subject: [Soap-Python] [RFR] instead of raising an exception on invalid
 input, just ignore it
Message-ID: <4CB9A425.9000701@arskom.com.tr>

 hi,

please comment on: http://github.com/arskom/soaplib/pull/37

thanks,
burak

ps: RFR == request for review. does it make sense?


From burak.arslan at arskom.com.tr  Sat Oct 16 15:11:20 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 16 Oct 2010 16:11:20 +0300
Subject: [Soap-Python] soaplib - python help
In-Reply-To: <19641.37246.671040.261251@cochabamba.vanoostrum.org>
References: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>	<4CB982F0.4050002@arskom.com.tr>
	<19641.37246.671040.261251@cochabamba.vanoostrum.org>
Message-ID: <4CB9A478.1040002@arskom.com.tr>

 On 10/16/10 14:50, Piet van Oostrum wrote:
> On 10/15/10 21:18, mukkera harsha wrote:
>  >
>  > I am getting the following error.
>  >
>  > Error ::
>  > ----------
>  >
>  >     for k, v in files.iteritems(): AttributeError: type object
>  > 'AnyAsDict' has no attribute 'iteritems'
>  >
>  > Code ::
>  > ------------
>  >
>  > class Subworkflow(ClassSerializer):
>  >         subworkflowid = String
>  >         files = AnyAsDict
>
> At least these two line should probably be:
>          subworkflowid = String()
>          files = AnyAsDict()
>

no, those two lines are actually correct.

you can do AnyAsDict(min_occurs=3) though.

burak.



From bradallen137 at gmail.com  Mon Oct 18 05:02:22 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sun, 17 Oct 2010 22:02:22 -0500
Subject: [Soap-Python] [RFR] instead of raising an exception on invalid
 input, just ignore it
In-Reply-To: <4CB9A425.9000701@arskom.com.tr>
References: <4CB9A425.9000701@arskom.com.tr>
Message-ID: <AANLkTikfqBAV9O_x0uG=KbJugsj8kQ11tatnUV=FMbC+@mail.gmail.com>

Chris or I will volunteer to take a look at this tomorrow.

On Sat, Oct 16, 2010 at 8:09 AM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:
> ?hi,
>
> please comment on: http://github.com/arskom/soaplib/pull/37
>
> thanks,
> burak
>
> ps: RFR == request for review. does it make sense?
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From bradallen137 at gmail.com  Mon Oct 18 05:25:17 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Sun, 17 Oct 2010 22:25:17 -0500
Subject: [Soap-Python] soaplib - python help
In-Reply-To: <4CB982F0.4050002@arskom.com.tr>
References: <AANLkTinr=WU2xwFi_YDiAfdUjhsdtd_Bq2kQWVn4cTPq@mail.gmail.com>
	<4CB982F0.4050002@arskom.com.tr>
Message-ID: <AANLkTimoL_O3kXgaeS3y=dX0_iB5d-N8VK35TD38sT9Q@mail.gmail.com>

On Sat, Oct 16, 2010 at 5:48 AM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:

> it looks like you're too much of a newbie for this forum. try a more
> python-centric forum for newbies for your questions.

Newbies are welcome here, Harshavardhan, but Burak is right that there
are better forums to help you with basic Python skills. (such as
http://mail.python.org/mailman/listinfo/tutor )

In this case you're getting an AttributeError, so you might want to
take a closer look at the object you are iterating over.  I recommend
trying a debugger such as pdb, so you can get to an interactive prompt
and take a close look at the files object (using something like the
dir function). Maybe it's not a Python dict object, if it doesn't have
an iteritems method.

http://docs.python.org/library/pdb.html


From bradallen137 at gmail.com  Tue Oct 19 17:30:58 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Tue, 19 Oct 2010 10:30:58 -0500
Subject: [Soap-Python] 0.8.2 stable release
In-Reply-To: <4CB81385.70105@arskom.com.tr>
References: <4CB81385.70105@arskom.com.tr>
Message-ID: <AANLkTik5GtnqnmKg-qhHDRkDR-SoFAzhwO9qnbLDc=qM@mail.gmail.com>

Some of my co-workers have tested 0.8.2 within Zope 2.12 and did not
find any problems.

On Fri, Oct 15, 2010 at 3:40 AM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:
> ?hi,
>
> i plan to release soaplib 0.8.2 stable release in the coming days.
>
> any objections?
>
> burak
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>


From dawalama at gmail.com  Tue Oct 19 21:11:50 2010
From: dawalama at gmail.com (Dawa Lama)
Date: Tue, 19 Oct 2010 15:11:50 -0400
Subject: [Soap-Python] problem trying to construct message in suds with
	<xsd:sequence .. namespace="##any"/>
Message-ID: <AANLkTi=Qym=o4-YBHBhrAxo6C8NS0Zif3e5dgmGEBoJ7@mail.gmail.com>

Hello All,

I am trying to use Suds to interact with third party SOAP service. I have
extracted out one of the types in wsdl I am having trouble with.


<xsd:complexType name="Content">
       <xsd:sequence>
       <xsd:any maxOccurs="1" minOccurs="1" namespace="##any"/>
       </xsd:sequence>
       <xsd:attribute name="id" type="xsd:ID" use="required"/>
       <xsd:anyAttribute/>
</xsd:complexType>

When I try to do the following :

> content  = client.factory.create('ns0:Content')
> print content
(Content){
   _id = ""
 }

My problem:
How do I add content to this object 'content'. For eg, I want to have
something like this

<Content id="x">
  <something_else_here/>
</Content>

It seems like I can only assign the 'id'.

Please help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101019/ddc210e7/attachment.html>

From florian.leitner at gmail.com  Mon Oct 25 12:53:58 2010
From: florian.leitner at gmail.com (Florian Leitner)
Date: Mon, 25 Oct 2010 12:53:58 +0200
Subject: [Soap-Python] soaplib and Python 3.x
Message-ID: <AANLkTikOKqeBdDPuPiwtyopsRWqi4wm-CihgvSnXWdKe@mail.gmail.com>

Hello everybody,

Could anybody quickly let me know if a) soaplib works under Python
3.x, or b) if anybody has successfully used that library after
applying 2to3?

Thanks,
Florian


From burak.arslan at arskom.com.tr  Mon Oct 25 15:51:03 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Mon, 25 Oct 2010 16:51:03 +0300
Subject: [Soap-Python] soaplib and Python 3.x
In-Reply-To: <AANLkTikOKqeBdDPuPiwtyopsRWqi4wm-CihgvSnXWdKe@mail.gmail.com>
References: <AANLkTikOKqeBdDPuPiwtyopsRWqi4wm-CihgvSnXWdKe@mail.gmail.com>
Message-ID: <4CC58B47.8030205@arskom.com.tr>

 On 10/25/10 13:53, Florian Leitner wrote:
> Hello everybody,
>
> Could anybody quickly let me know if a) soaplib works under Python
> 3.x, or b) if anybody has successfully used that library after
> applying 2to3?
>

which soaplib is it?

i don't think anybody reported his/her experience with python 3 and
soaplib. it'd be interesting to hear.

best regards,
burak




From gajendraph at gmail.com  Wed Oct 27 08:35:12 2010
From: gajendraph at gmail.com (Gajendra PH)
Date: Wed, 27 Oct 2010 12:05:12 +0530
Subject: [Soap-Python] how to add wsse security header
Message-ID: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>

Hi,

I am new to SOAP client programming. I want to add wsse security header in
my SOAP header.

I found that suds is providing this (suds.wsse) but not in SOAP WSDL Proxy.

Can any one help me how to do this in SOAP client using soaplib?

security=Security()
token=UsernameToken(username,password)
security.tokens.append(token)
client.set_options(wsse=security)

Thanks & Regards,
Gajendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101027/79038a83/attachment.html>

From burak.arslan at arskom.com.tr  Wed Oct 27 09:29:33 2010
From: burak.arslan at arskom.com.tr (Burak A.)
Date: Wed, 27 Oct 2010 10:29:33 +0300
Subject: [Soap-Python] how to add wsse security header
In-Reply-To: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>
References: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>
Message-ID: <1288164573.2191.5.camel@Nokia-N900>

----- Original message -----
> Hi,
> 
> I am new to SOAP client programming. I want to add wsse security header
> in my SOAP header.
> 
> I found that suds is providing this (suds.wsse) but not in SOAP WSDL
> Proxy.
> 
> Can any one help me how to do this in SOAP client using soaplib?
> 

sorry but soaplib currently doesn't have any wsse support.

burak 

> security=Security()
> token=UsernameToken(username,password)
> security.tokens.append(token)
> client.set_options(wsse=security)
> 
> Thanks & Regards,
> Gajendra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20101027/6ff45879/attachment.html>

From burak.arslan at arskom.com.tr  Wed Oct 27 12:12:33 2010
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Wed, 27 Oct 2010 13:12:33 +0300
Subject: [Soap-Python] soaplib and Python 3.x
In-Reply-To: <AANLkTimyE4C==91Vj78LFDSD_7PQgUkkjZihtfj5P421@mail.gmail.com>
References: <AANLkTikOKqeBdDPuPiwtyopsRWqi4wm-CihgvSnXWdKe@mail.gmail.com>
	<4CC58B47.8030205@arskom.com.tr>
	<AANLkTimyE4C==91Vj78LFDSD_7PQgUkkjZihtfj5P421@mail.gmail.com>
Message-ID: <4CC7FB11.3080509@arskom.com.tr>

 On 10/25/10 19:58, Florian Leitner wrote:
> Well, it would be most  interesting for your head version (the 1.0.0
> beta-8?) naturally, if nobody has done so. So, if currently nobody has
> done anything in that direction, maybe I can make some room to look
> into it; That would allow me to publish my Twisted asnyc wrapper for
> soaplib, too (didn't like the WSGI solution w/o deferreds...). But I
> still need to write quite a few missing tests before I feel safe
> releasing that into the wild - or into my production code...:).
> Currently, it might be a while before that pops up my todo-queue
> (work-overload :( ), but I'd really like to move on to Py3, with all
> the new nice stuff in it...
>

hello florian,

if you're after creating transport wrappers for soaplib, i'd suggest you
to look at the latest master. some substantial amount of work went into
that version so that we could offer a proper api to the people who'd
like to do that.

once the fix to the issue 49 is merged,
(http://github.com/arskom/soaplib/issues#issue/49) the (de)serialization
api can be considered stable, imo.

there's already support for zeromq and http transports. i think twisted
and django wrappers should be next.

just let us know when you manage to publish that work.

best regards,
burak


> Cheers,
> Florian
>
> On 25 October 2010 15:51, Burak Arslan <burak.arslan at arskom.com.tr> wrote:
>>  On 10/25/10 13:53, Florian Leitner wrote:
>>> Hello everybody,
>>>
>>> Could anybody quickly let me know if a) soaplib works under Python
>>> 3.x, or b) if anybody has successfully used that library after
>>> applying 2to3?
>>>
>> which soaplib is it?
>>
>> i don't think anybody reported his/her experience with python 3 and
>> soaplib. it'd be interesting to hear.
>>
>> best regards,
>> burak
>>
>>
>>



From joshua at eeinternet.com  Thu Oct 28 21:59:06 2010
From: joshua at eeinternet.com (Joshua J. Kugler)
Date: Thu, 28 Oct 2010 11:59:06 -0800
Subject: [Soap-Python] how to add wsse security header
In-Reply-To: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>
References: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>
Message-ID: <201010281159.06645.joshua@eeinternet.com>

On Tuesday 26 October 2010, Gajendra PH elucidated thus:
> Hi,
>
> I am new to SOAP client programming. I want to add wsse security
> header in my SOAP header.
>
> I found that suds is providing this (suds.wsse) but not in SOAP WSDL
> Proxy.
>
> Can any one help me how to do this in SOAP client using soaplib?
>
> security=Security()
> token=UsernameToken(username,password)
> security.tokens.append(token)
> client.set_options(wsse=security)

As Burak mentioned, soaplib does not support WSSE, but another Python 
SOAP client does. Take a look at https://fedorahosted.org/suds/ I can 
verify from first hand experience that its WSSE implementation works 
(at least with the Yahoo Marketing API).

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com - Fairbanks, AK
PGP Key: http://pgp.mit.edu/ ?ID 0x73B13B6A


From venable.devin at gmail.com  Thu Oct 28 23:13:33 2010
From: venable.devin at gmail.com (Devin Venable)
Date: Thu, 28 Oct 2010 16:13:33 -0500
Subject: [Soap-Python] how to add wsse security header
In-Reply-To: <201010281159.06645.joshua@eeinternet.com>
References: <AANLkTimgf0dgL-qxv=k0tK_KK2pEj01v1476g3ao2w-_@mail.gmail.com>
	<201010281159.06645.joshua@eeinternet.com>
Message-ID: <AANLkTiknDu4UOAEu3OD=PizEOUrSmi51JxHKqRxTUP8J@mail.gmail.com>

Suds wsse works, but it is lightweight.  If you only need UsernameToken, and
you don't need your password to be in digest form, it works.  If you need to
sign or encrypt elements in your body, you are still out of luck.  I tried
using a suds plugin to do my own signing using xmlsec, but having to switch
between DOM implementations is a pain, as SUDS uses its own and xmlsec uses
another.  In any case, good luck and be sure to point it out if you find a
robust solution.  For now, I've had to jump over to the JAVA side and use
WSS4J which is really mature.  We need an equivalent for Python.

On Thu, Oct 28, 2010 at 2:59 PM, Joshua J. Kugler <joshua at eeinternet.com>wrote:

> On Tuesday 26 October 2010, Gajendra PH elucidated thus:
> > Hi,
> >
> > I am new to SOAP client programming. I want to add wsse security
> > header in my SOAP header.
> >
> > I found that suds is providing this (suds.wsse) but not in SOAP WSDL
> > Proxy.
> >
> > Can any one help me how to do this in SOAP client using soaplib?
> >
> > security=Security()
> > token=UsernameToken(username,password)
> > security.tokens.append(token)
> > client.set_options(wsse=security)
>
> As Burak mentioned, soaplib does not support WSSE, but another Python
> SOAP client does. Take a look at https://fedorahosted.org/suds/ I can
> verify from first hand experience that its WSSE implementation works
> (at least with the Yahoo Marketing API).
>
> j
>
> --
> Joshua Kugler
> Part-Time System Admin/Programmer
> http://www.eeinternet.com - Fairbanks, AK
> PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A
> _______________________________________________
> 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/20101028/9339852f/attachment.html>