From wladston at 2xt.com.br  Tue May 10 01:09:39 2011
From: wladston at 2xt.com.br (Wladston Viana)
Date: Mon, 9 May 2011 20:09:39 -0300
Subject: [Soap-Python] Soaplib's Any and AnyDict serializers
Message-ID: <BANLkTimxCqnFbZbeVFOE_+kkZ8ERfxvcLA@mail.gmail.com>

Hello,

Could anyone provide me a code sample of Any and AnyDict on soaplib ?

I can't use those serializers, and I think I might be doing it totally
wrong, since there isn't any documentation of them on soaplib's
documentation.

Thanks,

-- 
Wladston Viana
Estagi?rio
"O segredo de toda vit?ria ? a organiza??o do n?o-?bvio"
wladston at 2xt.com.br
+55 31 3292-2120 | www.2xt.com.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110509/8af7ab33/attachment.html>

From burak.arslan at arskom.com.tr  Sat May 14 11:05:11 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 14 May 2011 12:05:11 +0300
Subject: [Soap-Python] Soaplib's Any and AnyDict serializers
In-Reply-To: <BANLkTimxCqnFbZbeVFOE_+kkZ8ERfxvcLA@mail.gmail.com>
References: <BANLkTimxCqnFbZbeVFOE_+kkZ8ERfxvcLA@mail.gmail.com>
Message-ID: <4DCE45C7.4040809@arskom.com.tr>

 On 05/10/11 02:09, Wladston Viana wrote:
> Hello,
>
> Could anyone provide me a code sample of Any and AnyDict on soaplib ? 
>
>


the Any type is actually an lxml.etree._Element object. the AnyAsDict
type is in turn a native dict formatted like this:

https://github.com/arskom/rpclib/blob/master/src/rpclib/test/interop/_test_client_base.py#L101

the source code for the Any and AnyAsDict types are pretty simple. (they
almost do nothing)

https://github.com/arskom/rpclib/blob/master/src/rpclib/model/primitive.py#L50

it'd be nice if you could create an isolated example and send it to the
ml so we can add it to the documentation.

best,
burak



From paolo.losi at gmail.com  Mon May 16 12:25:30 2011
From: paolo.losi at gmail.com (Paolo Losi)
Date: Mon, 16 May 2011 12:25:30 +0200
Subject: [Soap-Python] suds and soaplib without internet access
Message-ID: <BANLkTimFTUT4h-Ybag=5+XvzN28y_EUg7A@mail.gmail.com>

Hi all,

I'm trying soaplib master branch (checked out yesterday) against suds (0.4)
in an enviroment without internet access.

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

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

Is there a way to configure soaplib not to trigger suds behaviour?

Thanks!

Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110516/6068b992/attachment.html>

From aymeric.augustin at polyconseil.fr  Mon May 16 16:16:17 2011
From: aymeric.augustin at polyconseil.fr (Aymeric Augustin)
Date: Mon, 16 May 2011 16:16:17 +0200
Subject: [Soap-Python] suds and soaplib without internet access
In-Reply-To: <BANLkTimFTUT4h-Ybag=5+XvzN28y_EUg7A@mail.gmail.com>
References: <BANLkTimFTUT4h-Ybag=5+XvzN28y_EUg7A@mail.gmail.com>
Message-ID: <D54566EC-CD4B-4544-AB85-178D2CB0B209@polyconseil.fr>

Hi Paolo,

We're using this code to avoid hitting w3.org during the tests:

import os.path
from suds.xsd import sxbasic
sxbasic.Import.bind('http://www.w3.org/2001/XMLSchema',
                    'file://' + os.path.join(ROOT_DIR, 'cache', 'suds', 'XMLSchema.xml'))

And we store a copy of XMLSchema.xml in ROOT_DIR/cache/suds/.

Actually, we discovered this after we got blacklisted ? see http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/

Best regards,

Aymeric Augustin.

On 16 mai 2011, at 12:25, Paolo Losi wrote:

> Hi all,
> 
> I'm trying soaplib master branch (checked out yesterday) against suds (0.4)
> in an enviroment without internet access.
> 
> The problem with suds is that it tries to download from the internet XMLSchema.xsd
> without success:
> 
> DEBUG:suds.xsd.sxbasic:Import:0xb7808a6cL, importing ns="http://www.w3.org/2001/XMLSchema", location="http://www.w3.org/2001/XMLSchema.xsd"
> DEBUG:suds.transport.http:opening (http://www.w3.org/2001/XMLSchema.xsd)
> Traceback (most recent call last):
> .....
> urllib2.URLError: <urlopen error timed out>
> 
> Is there a way to configure soaplib not to trigger suds behaviour?
> 
> Thanks!
> 
> Paolo
> _______________________________________________
> 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/20110516/774d971b/attachment.html>

From aymeric.augustin at polyconseil.fr  Tue May 17 12:33:46 2011
From: aymeric.augustin at polyconseil.fr (Aymeric Augustin)
Date: Tue, 17 May 2011 12:33:46 +0200
Subject: [Soap-Python] suds and soaplib without internet access
In-Reply-To: <BANLkTi=mfF=kM=zXwQ2fAmzB4JJq_p35uA@mail.gmail.com>
References: <BANLkTimFTUT4h-Ybag=5+XvzN28y_EUg7A@mail.gmail.com>
	<D54566EC-CD4B-4544-AB85-178D2CB0B209@polyconseil.fr>
	<BANLkTi=mfF=kM=zXwQ2fAmzB4JJq_p35uA@mail.gmail.com>
Message-ID: <941EF918-7165-4FF2-8B43-60DB5D14D00B@polyconseil.fr>

Hi Paolo,

Actually, we've put the contents of http://www.w3.org/2001/XMLSchema.html in cache/suds/XMLSchema.xml, and suds works just fine with that.

I'm not sufficiently familiar with SOAP to be positive, but here's what I understand from http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/:
  - http://www.w3.org/2001/XMLSchema is just a standard identifier, it's not meant to be fetched
  - SOAP should not depend on the content hosted at that URL
  - One may consider that the fact that suds fetches this URL is a bug in suds.

Best regards,

Aymeric AUGUSTIN
Polyconseil | 11bis, rue Scribe | 75009 Paris
mob : (+33) 6 22 43 79 99
tel : (+33) 1 58 18 67 40 | fax : (+33) 1 47 42 38 32

On 17 mai 2011, at 12:08, Paolo Losi wrote:

> Hi Aymeric,
> 
> thanks for your reply :-)
> 
> On Mon, May 16, 2011 at 4:16 PM, Aymeric Augustin <aymeric.augustin at polyconseil.fr> wrote:
> Hi Paolo,
> 
> We're using this code to avoid hitting w3.org during the tests:
> 
> import os.path
> from suds.xsd import sxbasic
> sxbasic.Import.bind('http://www.w3.org/2001/XMLSchema',
>                     'file://' + os.path.join(ROOT_DIR, 'cache', 'suds', 'XMLSchema.xml'))
> 
> And we store a copy of XMLSchema.xml in ROOT_DIR/cache/suds/.
> 
> I tested your workaround but suds hit the net again for xml.xsd.
> 
> DEBUG:suds.xsd.sxbasic:Import:0xb749c5ecL, importing ns="http://www.w3.org/XML/1998/namespace", location="http://www.w3.org/2001/xml.xsd"
> DEBUG:suds.transport.http:opening (http://www.w3.org/2001/xml.xsd)
> 
> That schema is imported by XMLSchema.xsd by specifying explicitely
> a schemaLocation. So adding the following line doesn't help (suds ignores it).
> 
> sxbasic.Import.bind('http://www.w3.org/XML/1998/namespace', 'file:///my_path/xml.xsd')
> 
> Didn't you have the same problem?
> Is there a way to avoid triggering all these imports on soaplib side?
> I'm using suds with other wsdl and complex types and no internet access
> without sperimenting these problems...
> 
> Thanks again!
> 
> Paolo

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

From paolo.losi at gmail.com  Tue May 17 12:08:13 2011
From: paolo.losi at gmail.com (Paolo Losi)
Date: Tue, 17 May 2011 12:08:13 +0200
Subject: [Soap-Python] suds and soaplib without internet access
In-Reply-To: <D54566EC-CD4B-4544-AB85-178D2CB0B209@polyconseil.fr>
References: <BANLkTimFTUT4h-Ybag=5+XvzN28y_EUg7A@mail.gmail.com>
	<D54566EC-CD4B-4544-AB85-178D2CB0B209@polyconseil.fr>
Message-ID: <BANLkTi=mfF=kM=zXwQ2fAmzB4JJq_p35uA@mail.gmail.com>

Hi Aymeric,

thanks for your reply :-)

On Mon, May 16, 2011 at 4:16 PM, Aymeric Augustin <
aymeric.augustin at polyconseil.fr> wrote:

> Hi Paolo,
>
> We're using this code to avoid hitting w3.org during the tests:
>
> import os.path
> from suds.xsd import sxbasic
> sxbasic.Import.bind('http://www.w3.org/2001/XMLSchema',
>                     'file://' + os.path.join(ROOT_DIR, 'cache', 'suds',
> 'XMLSchema.xml'))
>
> And we store a copy of XMLSchema.xml in ROOT_DIR/cache/suds/.
>

I tested your workaround but suds hit the net again for xml.xsd.

DEBUG:suds.xsd.sxbasic:Import:0xb749c5ecL, importing ns="
http://www.w3.org/XML/1998/namespace", location="
http://www.w3.org/2001/xml.xsd"
DEBUG:suds.transport.http:opening (http://www.w3.org/2001/xml.xsd)

That schema is imported by XMLSchema.xsd by specifying explicitely
a schemaLocation. So adding the following line doesn't help (suds ignores
it).

sxbasic.Import.bind('http://www.w3.org/XML/1998/namespace',
'file:///my_path/xml.xsd')

Didn't you have the same problem?
Is there a way to avoid triggering all these imports on soaplib side?
I'm using suds with other wsdl and complex types and no internet access
without sperimenting these problems...

Thanks again!

Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110517/062eea87/attachment.html>

From burak.arslan at arskom.com.tr  Sat May 21 16:36:30 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Sat, 21 May 2011 17:36:30 +0300
Subject: [Soap-Python] rpclib and soaplib
Message-ID: <4DD7CDEE.1080201@arskom.com.tr>


hello everyone,

i found myself with some free time on my hands, and plan to hack rpclib
some more.

i've been looking into the work that went into soaplib in the past
months and applying the changes as i go along to the rpclib codebase.
wasn't so hard so far.

as you might remember, the promise of soaplib-3.0 was to support
multiple soap/wsdl versions. while doing that i'd realised that it'd
became trivial to add other protocols, so i went forward and added them,
which rendered the soaplib name rather inappropriate. so i renamed the
package to rpclib and just when i finished the job, i had to go offline
abruptly for some time.

now that i'm back, i see that we ended up with two soap codebases. i
think (and i'm sure you'll agree) that this town is too big for both of
them.

so, after i go over all of your changes, i see two ways forward:

1) you guys drop soaplib and work on soap parts of rpclib.
2) i remove soap code from rpclib and use soap logic from soaplib. to do
that you'd have to redo part of what i did for soaplib to support the
new protocol api, so that i can wrap soaplib code inside rpclib.

why should you care?
if ever you'll want to support multiple soap versions inside one soaplib
package, you'll have to redo what i did for soaplib to become rpclib. if
you're confident that you'll be happy forever with soap/wsdl 1.1 pairs,
you can just ignore me.

so, what do we do now?

best,
burak

From burak.arslan at arskom.com.tr  Mon May 23 14:07:05 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Mon, 23 May 2011 15:07:05 +0300
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <4DD7CDEE.1080201@arskom.com.tr>
References: <4DD7CDEE.1080201@arskom.com.tr>
Message-ID: <4DDA4DE9.6000708@arskom.com.tr>

On 05/21/11 17:36, Burak Arslan wrote:
> now that i'm back, i see that we ended up with two soap codebases. i
> think (and i'm sure you'll agree) that this town is too big for both of
> them.
>

um, small.

> so, after i go over all of your changes, i see two ways forward:

which i just finished doing. i relied a lot on the tests. i hope their
coverage is enough.

i didn't merge anything documentation-related. i'm waiting for your
feedback to do that.

cheers,
burak


From chris at sydneysys.com  Mon May 23 18:19:09 2011
From: chris at sydneysys.com (Chris Austin)
Date: Mon, 23 May 2011 11:19:09 -0500
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <4DD7CDEE.1080201@arskom.com.tr>
References: <4DD7CDEE.1080201@arskom.com.tr>
Message-ID: <BANLkTi=afhP8vmyRAvO_xRFbrg251KAvTQ@mail.gmail.com>

Welcome back Burak,

I tend to prefer the latter approach.  But, before we start looking at
merging the code from rpclib's soap components there some real
structural changes that I are needed in soaplib.  In particular, there
is a lot of tight coupling between a lot of the core classes and
_base.Application knows way too much about other classes.  Minor stuff
in the scheme of things but I hate breaking the api to often.

But sure, lets do what we can and make this work.

On Sat, May 21, 2011 at 9:36 AM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:
>
> hello everyone,
>
> i found myself with some free time on my hands, and plan to hack rpclib
> some more.
>
> i've been looking into the work that went into soaplib in the past
> months and applying the changes as i go along to the rpclib codebase.
> wasn't so hard so far.
>
> as you might remember, the promise of soaplib-3.0 was to support
> multiple soap/wsdl versions. while doing that i'd realised that it'd
> became trivial to add other protocols, so i went forward and added them,
> which rendered the soaplib name rather inappropriate. so i renamed the
> package to rpclib and just when i finished the job, i had to go offline
> abruptly for some time.
>
> now that i'm back, i see that we ended up with two soap codebases. i
> think (and i'm sure you'll agree) that this town is too big for both of
> them.
>
> so, after i go over all of your changes, i see two ways forward:
>
> 1) you guys drop soaplib and work on soap parts of rpclib.
> 2) i remove soap code from rpclib and use soap logic from soaplib. to do
> that you'd have to redo part of what i did for soaplib to support the
> new protocol api, so that i can wrap soaplib code inside rpclib.
>
> why should you care?
> if ever you'll want to support multiple soap versions inside one soaplib
> package, you'll have to redo what i did for soaplib to become rpclib. if
> you're confident that you'll be happy forever with soap/wsdl 1.1 pairs,
> you can just ignore me.
>
> so, what do we do now?
>
> best,
> burak
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>

From bradallen137 at gmail.com  Mon May 23 21:52:51 2011
From: bradallen137 at gmail.com (Brad Allen)
Date: Mon, 23 May 2011 14:52:51 -0500
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <BANLkTi=afhP8vmyRAvO_xRFbrg251KAvTQ@mail.gmail.com>
References: <4DD7CDEE.1080201@arskom.com.tr>
	<BANLkTi=afhP8vmyRAvO_xRFbrg251KAvTQ@mail.gmail.com>
Message-ID: <BANLkTi=roLL98XXt+KRnbN2VT+tONS4ixg@mail.gmail.com>

Burak, you created the rpclib fork to support your vision for a
generic RPC library, right?

Meanwhile, soaplib should focus on providing a stable, well-tested,
well-documented SOAP-compliant server for the Python community. Trying
to support generic RPC cases might be a distraction from the basic
mission of supporting the SOAP specification.

I agree that we might want to add support for SOAP 1.2 at some point
in the future, but that is too big a project for the soaplib 2.0
release (which is very close to final right now).

On Mon, May 23, 2011 at 11:19 AM, Chris Austin <chris at sydneysys.com> wrote:
> Welcome back Burak,
>
> I tend to prefer the latter approach. ?But, before we start looking at
> merging the code from rpclib's soap components there some real
> structural changes that I are needed in soaplib. ?In particular, there
> is a lot of tight coupling between a lot of the core classes and
> _base.Application knows way too much about other classes. ?Minor stuff
> in the scheme of things but I hate breaking the api to often.
>
> But sure, lets do what we can and make this work.
>
> On Sat, May 21, 2011 at 9:36 AM, Burak Arslan
> <burak.arslan at arskom.com.tr> wrote:
>>
>> hello everyone,
>>
>> i found myself with some free time on my hands, and plan to hack rpclib
>> some more.
>>
>> i've been looking into the work that went into soaplib in the past
>> months and applying the changes as i go along to the rpclib codebase.
>> wasn't so hard so far.
>>
>> as you might remember, the promise of soaplib-3.0 was to support
>> multiple soap/wsdl versions. while doing that i'd realised that it'd
>> became trivial to add other protocols, so i went forward and added them,
>> which rendered the soaplib name rather inappropriate. so i renamed the
>> package to rpclib and just when i finished the job, i had to go offline
>> abruptly for some time.
>>
>> now that i'm back, i see that we ended up with two soap codebases. i
>> think (and i'm sure you'll agree) that this town is too big for both of
>> them.
>>
>> so, after i go over all of your changes, i see two ways forward:
>>
>> 1) you guys drop soaplib and work on soap parts of rpclib.
>> 2) i remove soap code from rpclib and use soap logic from soaplib. to do
>> that you'd have to redo part of what i did for soaplib to support the
>> new protocol api, so that i can wrap soaplib code inside rpclib.
>>
>> why should you care?
>> if ever you'll want to support multiple soap versions inside one soaplib
>> package, you'll have to redo what i did for soaplib to become rpclib. if
>> you're confident that you'll be happy forever with soap/wsdl 1.1 pairs,
>> you can just ignore me.
>>
>> so, what do we do now?
>>
>> 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
>

From ovnicraft at gmail.com  Mon May 23 22:46:45 2011
From: ovnicraft at gmail.com (Ovnicraft)
Date: Mon, 23 May 2011 15:46:45 -0500
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <BANLkTi=roLL98XXt+KRnbN2VT+tONS4ixg@mail.gmail.com>
References: <4DD7CDEE.1080201@arskom.com.tr>
	<BANLkTi=afhP8vmyRAvO_xRFbrg251KAvTQ@mail.gmail.com>
	<BANLkTi=roLL98XXt+KRnbN2VT+tONS4ixg@mail.gmail.com>
Message-ID: <BANLkTikUy+bZU3qRyhx_8ryP_efYazLHtQ@mail.gmail.com>

On Mon, May 23, 2011 at 2:52 PM, Brad Allen <bradallen137 at gmail.com> wrote:

> Burak, you created the rpclib fork to support your vision for a
> generic RPC library, right?
>
> Meanwhile, soaplib should focus on providing a stable, well-tested,
> well-documented SOAP-compliant server for the Python community. Trying
> to support generic RPC cases might be a distraction from the basic
> mission of supporting the SOAP specification.
>
>
Completely agree, until get well-tested server IMHO project dont need to
merge with another issues, it does not means can exists a fork about
rpc-soap and can maintain who will merge in a near future his project.

Regards,


> I agree that we might want to add support for SOAP 1.2 at some point
> in the future, but that is too big a project for the soaplib 2.0
> release (which is very close to final right now).
>
> On Mon, May 23, 2011 at 11:19 AM, Chris Austin <chris at sydneysys.com>
> wrote:
> > Welcome back Burak,
> >
> > I tend to prefer the latter approach.  But, before we start looking at
> > merging the code from rpclib's soap components there some real
> > structural changes that I are needed in soaplib.  In particular, there
> > is a lot of tight coupling between a lot of the core classes and
> > _base.Application knows way too much about other classes.  Minor stuff
> > in the scheme of things but I hate breaking the api to often.
> >
> > But sure, lets do what we can and make this work.
> >
> > On Sat, May 21, 2011 at 9:36 AM, Burak Arslan
> > <burak.arslan at arskom.com.tr> wrote:
> >>
> >> hello everyone,
> >>
> >> i found myself with some free time on my hands, and plan to hack rpclib
> >> some more.
> >>
> >> i've been looking into the work that went into soaplib in the past
> >> months and applying the changes as i go along to the rpclib codebase.
> >> wasn't so hard so far.
> >>
> >> as you might remember, the promise of soaplib-3.0 was to support
> >> multiple soap/wsdl versions. while doing that i'd realised that it'd
> >> became trivial to add other protocols, so i went forward and added them,
> >> which rendered the soaplib name rather inappropriate. so i renamed the
> >> package to rpclib and just when i finished the job, i had to go offline
> >> abruptly for some time.
> >>
> >> now that i'm back, i see that we ended up with two soap codebases. i
> >> think (and i'm sure you'll agree) that this town is too big for both of
> >> them.
> >>
> >> so, after i go over all of your changes, i see two ways forward:
> >>
> >> 1) you guys drop soaplib and work on soap parts of rpclib.
> >> 2) i remove soap code from rpclib and use soap logic from soaplib. to do
> >> that you'd have to redo part of what i did for soaplib to support the
> >> new protocol api, so that i can wrap soaplib code inside rpclib.
> >>
> >> why should you care?
> >> if ever you'll want to support multiple soap versions inside one soaplib
> >> package, you'll have to redo what i did for soaplib to become rpclib. if
> >> you're confident that you'll be happy forever with soap/wsdl 1.1 pairs,
> >> you can just ignore me.
> >>
> >> so, what do we do now?
> >>
> >> 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
> >
> _______________________________________________
> 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/20110523/99aa5c72/attachment-0001.html>

From burak.arslan at arskom.com.tr  Tue May 24 12:03:09 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Tue, 24 May 2011 13:03:09 +0300
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <BANLkTi=roLL98XXt+KRnbN2VT+tONS4ixg@mail.gmail.com>
References: <4DD7CDEE.1080201@arskom.com.tr>
	<BANLkTi=afhP8vmyRAvO_xRFbrg251KAvTQ@mail.gmail.com>
	<BANLkTi=roLL98XXt+KRnbN2VT+tONS4ixg@mail.gmail.com>
Message-ID: <1306231389.18735.4.camel@Nokia-N900>

----- Original message -----
> Burak, you created the rpclib fork to support your vision for a
> generic RPC library, right?
>
> Meanwhile, soaplib should focus on providing a stable, well-tested,
> well-documented SOAP-compliant server for the Python community. Trying
> to support generic RPC cases might be a distraction from the basic
> mission of supporting the SOAP specification.
>

hi brad,

Again, I'm saying two things: first, that my code is out there with many of the things you're going to have to do already done, and also that we should not split our already limited development resources and keep only one of the code bases. 

If you want to keep soaplib, you should give me an api so that i can wrap soaplib code and remove soap code from rpclib. If you're to drop it (which, apparently, you're not willing to) you can already do it with zero effort, because i've ported most of your work to rpclib anyway.

Please don't misunderstand this as it's my just my honest advice: i wouldn't keep soaplib, or even if I did, i'd fork rpclib, rename it back to soaplib and remove non-soap code. That seems a more reasonable approach given the amount of resources you've dedicated to soaplib development so far.

Best,
burak

> On Mon, May 23, 2011 at 11:19 AM, Chris Austin <chris at sydneysys.com>
> wrote:
> > Welcome back Burak,
> >
> > I tend to prefer the latter approach. ?But, before we start looking at
> > merging the code from rpclib's soap components there some real
> > structural changes that I are needed in soaplib. ?In particular, there
> > is a lot of tight coupling between a lot of the core classes and
> > _base.Application knows way too much about other classes. ?Minor stuff
> > in the scheme of things but I hate breaking the api to often.
> >
> > But sure, lets do what we can and make this work.
> >
> > On Sat, May 21, 2011 at 9:36 AM, Burak Arslan
> > <burak.arslan at arskom.com.tr> wrote:
> > >
> > > hello everyone,
> > >
> > > i found myself with some free time on my hands, and plan to hack
> > > rpclib some more.
> > >
> > > i've been looking into the work that went into soaplib in the past
> > > months and applying the changes as i go along to the rpclib codebase.
> > > wasn't so hard so far.
> > >
> > > as you might remember, the promise of soaplib-3.0 was to support
> > > multiple soap/wsdl versions. while doing that i'd realised that it'd
> > > became trivial to add other protocols, so i went forward and added
> > > them, which rendered the soaplib name rather inappropriate. so i
> > > renamed the package to rpclib and just when i finished the job, i
> > > had to go offline abruptly for some time.
> > >
> > > now that i'm back, i see that we ended up with two soap codebases. i
> > > think (and i'm sure you'll agree) that this town is too big for both
> > > of them.
> > >
> > > so, after i go over all of your changes, i see two ways forward:
> > >
> > > 1) you guys drop soaplib and work on soap parts of rpclib.
> > > 2) i remove soap code from rpclib and use soap logic from soaplib.
> > > to do that you'd have to redo part of what i did for soaplib to
> > > support the new protocol api, so that i can wrap soaplib code inside
> > > rpclib.
> > >
> > > why should you care?
> > > if ever you'll want to support multiple soap versions inside one
> > > soaplib package, you'll have to redo what i did for soaplib to
> > > become rpclib. if you're confident that you'll be happy forever with
> > > soap/wsdl 1.1 pairs, you can just ignore me.
> > >
> > > so, what do we do now?
> > >
> > > 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
> >
> _______________________________________________
> 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/20110524/cb2182a4/attachment.html>

From dieter at handshake.de  Wed May 25 12:23:31 2011
From: dieter at handshake.de (Dieter Maurer)
Date: Wed, 25 May 2011 12:23:31 +0200
Subject: [Soap-Python] rpclib and soaplib
In-Reply-To: <1306231389.18735.4.camel@Nokia-N900>
References: <1306231389.18735.4.camel@Nokia-N900>
Message-ID: <19932.55459.102718.908582@localhost.localdomain>

Burak Arslan wrote at 2011-5-24 13:03 +0300:
> ...
>Please don't misunderstand this as it's my just my honest advice: i wouldn't keep soaplib, or even if I did, i'd fork rpclib, rename it back to soaplib and remove non-soap code. That seems a more reasonable approach given the amount of resources you've dedicated to soaplib development so far.

Names are highly important.

Thus, if someone is interested in SOAP (and Python), "soaplib" is
directly interesting for him. Background information is necessary,
to recognize that "rpclib" may be relevant for him.

Thus, I would keep both "soaplib" and "rpclib" -- as names
of PyPI released packages.


I agree that significant redundant code in both "soaplib" and "rpclib"
looks not promising. Based on the names, I would put soap specifics
into "soaplib" and let it use by "rpclib".

Maybe, we want even a third PyPI package containing non soap related
common functionality helpfull for both "soaplib" and "rpclib".



--
Dieter

From erevilla at yaco.es  Fri May 27 00:16:56 2011
From: erevilla at yaco.es (Ernesto Revilla Derksen)
Date: Fri, 27 May 2011 00:16:56 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header processing
 (aka ws-security, etc.)
Message-ID: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>

Hi.

First of all, you're doing a great work with soaplib!!!

I was just running the debugger to see how soaplibs treats the headers.

In soaplib/core/_base.py:decompose_incoming_envelope (near line 335), we get
the header & body parsed. Fine!

But just below, there is no self.validateHeader or self.checkHeader. So the
body is validated before (!) any headers can be validades. Could there be a
hook?

In method deserialize_soap (lines 406-417):
            # decode header object
            if (ctx.in_header_xml is not None and
                len(ctx.in_header_xml) > 0 and
                header_class is not None):
                ctx.service.in_header =
header_class.from_xml(ctx.in_header_xml)


how do IN-wrappers supposed to work? could you give an example?

In process_request (line 436):
ctx.service.on_method_call(ctx.method_name,req_obj,ctx.in_body_xml)

the header is NOT sent to the service hook

As I can see (and sure that I'm wrong), I have the following alternatives of
processing SOAP headers:
 - using IN-wrappers:
 - override Application object customizing one of:
   - deserialize_soap (says: not meant to be override!)
   - decompose_incoming_envelope
   - process_request (says: not meant to be override!)

Where would be the best place to implement header checking? (e.g. security=

Thanks in advance.
Best regards.
Erny
Spain

Ernesto Revilla
Yaco Sistemas
+34 954 500 057
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110527/8350776e/attachment.html>

From chris at sydneysys.com  Fri May 27 00:55:26 2011
From: chris at sydneysys.com (Chris Austin)
Date: Thu, 26 May 2011 17:55:26 -0500
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
Message-ID: <BANLkTikk5e3mb+=Q+-+chgi8zeb98_rmDg@mail.gmail.com>

On Thu, May 26, 2011 at 5:16 PM, Ernesto Revilla Derksen
<erevilla at yaco.es> wrote:
> Hi.
> First of all, you're doing a great work with soaplib!!!
> I was just running the debugger to see how soaplibs treats the headers.
> In soaplib/core/_base.py:decompose_incoming_envelope (near line 335), we get
> the header & body parsed. Fine!
> But just below, there is no self.validateHeader or self.checkHeader. So the
> body is validated before (!) any headers can be validades. Could there be a
> hook?
> In method deserialize_soap (lines 406-417):
> ? ? ? ? ? ? # decode header object
> ? ? ? ? ? ? if (ctx.in_header_xml is not None and
> ? ? ? ? ? ? ? ? len(ctx.in_header_xml) > 0 and
> ? ? ? ? ? ? ? ? header_class is not None):
> ? ? ? ? ? ? ? ? ctx.service.in_header =
> header_class.from_xml(ctx.in_header_xml)
>
> how do IN-wrappers supposed to work? could you give an example?

Sure, this is taken from the test at
https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/server/_service.py

You can define your headers as follows.

class InHeader(ClassModel):
    s=String
    i=Integer

class OutHeader(ClassModel):
    dt=DateTime
    f=Float

Now, you can write a service  that references your headers and, you
can get access to the headers in your web methods as echo_in_header()
and send_out_header() do below.

class InteropServiceWithHeader(service.DefinitionBase):
    __in_header__ = InHeader
    __out_header__ = OutHeader

    @soap(_returns=InHeader)
    def echo_in_header(self):
        return self.in_header

    @soap(_returns=OutHeader)
    def send_out_header(self):
        self.out_header = OutHeader()
        self.out_header.dt = datetime(year=2000, month=01, day=01)
        self.out_header.f = 3.141592653

        return self.out_header


Now, you can work with the headers in you client following something
similar to the following example which is also take from an interop
test found at :https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/test_suds.py

So, you can treat headers just like any other datatype exposed by the service.

def test_echo_in_header(self):
        in_header = self.client.factory.create('InHeader')
        in_header.s = 'a'
        in_header.i = 3

        self.client.set_options(soapheaders=in_header)
        ret = self.client.service.echo_in_header()
        self.client.set_options(soapheaders=None)

        print ret

        self.assertEquals(in_header.s, ret.s)
        self.assertEquals(in_header.i, ret.i)

    def test_send_out_header(self):
        out_header = self.client.factory.create('OutHeader')
        out_header.dt = datetime(year=2000, month=01, day=01)
        out_header.f = 3.141592653

        ret = self.client.service.send_out_header()

        self.assertTrue(isinstance(ret,type(out_header)))
        self.assertEquals(ret.dt, out_header.dt)
        self.assertEquals(ret.f, out_header.f)


I hope this helps.

> In process_request (line 436):
> ctx.service.on_method_call(ctx.method_name,req_obj,ctx.in_body_xml)
> the header is NOT sent to the service hook
> As I can see (and sure that I'm wrong), I have the following alternatives of
> processing SOAP headers:
> ?- using IN-wrappers:
> ?- override Application object customizing one of:
> ? ?- deserialize_soap?(says: not meant to be override!)
> ? ?- decompose_incoming_envelope
> ? ?-?process_request (says: not meant to be override!)
> Where would be the best place to implement header checking? (e.g. security=
> Thanks in advance.
> Best regards.
> Erny
> Spain
> Ernesto Revilla
> Yaco Sistemas
> +34 954 500 057
>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap
>
>

From erevilla at yaco.es  Fri May 27 01:56:12 2011
From: erevilla at yaco.es (Ernesto Revilla Derksen)
Date: Fri, 27 May 2011 01:56:12 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTikk5e3mb+=Q+-+chgi8zeb98_rmDg@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
	<BANLkTikk5e3mb+=Q+-+chgi8zeb98_rmDg@mail.gmail.com>
Message-ID: <BANLkTinNpKw9-X3XMaq9A5+ogR3q+g+ymA@mail.gmail.com>

Hi again.

Now I am extracting de security data as follows (really easy!):
...
ns_wsse = "
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
"

class UsernameTokenType(ClassModel):
    __namespace__ = ns_wsse
    Username = String
    Password = String
    Nonce = String


class Security(ClassModel):
    __namespace__ = ns_wsse
    UsernameToken = UsernameTokenType


class HelloWorldService(DefinitionBase):
    __in_header__ = Security

    def on_method_call(self, method_name, py_params, soap_params):
        # I can't access self.in_header here!
        pass

    @soap(String, Integer, _returns=Array(String))
    def say_hello(self, name, times):
        # We have access to self.in_header here.
        results = []
        for i in range(0, times):
            results.append('Hello, %s' % name)
        return results

To implement a service wide authentication procedure, I would have to
implement it as decorator, as the method "on_method_call" has no access to
"in_header".

Any other suggestions?

Regards.
Erny

2011/5/27 Chris Austin <chris at sydneysys.com>

> On Thu, May 26, 2011 at 5:16 PM, Ernesto Revilla Derksen
> <erevilla at yaco.es> wrote:
> > Hi.
> > First of all, you're doing a great work with soaplib!!!
> > I was just running the debugger to see how soaplibs treats the headers.
> > In soaplib/core/_base.py:decompose_incoming_envelope (near line 335), we
> get
> > the header & body parsed. Fine!
> > But just below, there is no self.validateHeader or self.checkHeader. So
> the
> > body is validated before (!) any headers can be validades. Could there be
> a
> > hook?
> > In method deserialize_soap (lines 406-417):
> >             # decode header object
> >             if (ctx.in_header_xml is not None and
> >                 len(ctx.in_header_xml) > 0 and
> >                 header_class is not None):
> >                 ctx.service.in_header =
> > header_class.from_xml(ctx.in_header_xml)
> >
> > how do IN-wrappers supposed to work? could you give an example?
>
> Sure, this is taken from the test at
>
> https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/server/_service.py
>
> You can define your headers as follows.
>
> class InHeader(ClassModel):
>    s=String
>    i=Integer
>
> class OutHeader(ClassModel):
>    dt=DateTime
>    f=Float
>
> Now, you can write a service  that references your headers and, you
> can get access to the headers in your web methods as echo_in_header()
> and send_out_header() do below.
>
> class InteropServiceWithHeader(service.DefinitionBase):
>    __in_header__ = InHeader
>    __out_header__ = OutHeader
>
>    @soap(_returns=InHeader)
>    def echo_in_header(self):
>        return self.in_header
>
>    @soap(_returns=OutHeader)
>    def send_out_header(self):
>        self.out_header = OutHeader()
>        self.out_header.dt = datetime(year=2000, month=01, day=01)
>        self.out_header.f = 3.141592653
>
>        return self.out_header
>
>
> Now, you can work with the headers in you client following something
> similar to the following example which is also take from an interop
> test found at :
> https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/test_suds.py
>
> So, you can treat headers just like any other datatype exposed by the
> service.
>
> def test_echo_in_header(self):
>        in_header = self.client.factory.create('InHeader')
>        in_header.s = 'a'
>        in_header.i = 3
>
>        self.client.set_options(soapheaders=in_header)
>        ret = self.client.service.echo_in_header()
>        self.client.set_options(soapheaders=None)
>
>        print ret
>
>        self.assertEquals(in_header.s, ret.s)
>        self.assertEquals(in_header.i, ret.i)
>
>    def test_send_out_header(self):
>        out_header = self.client.factory.create('OutHeader')
>        out_header.dt = datetime(year=2000, month=01, day=01)
>        out_header.f = 3.141592653
>
>        ret = self.client.service.send_out_header()
>
>        self.assertTrue(isinstance(ret,type(out_header)))
>        self.assertEquals(ret.dt, out_header.dt)
>        self.assertEquals(ret.f, out_header.f)
>
>
> I hope this helps.
>
> > In process_request (line 436):
> > ctx.service.on_method_call(ctx.method_name,req_obj,ctx.in_body_xml)
> > the header is NOT sent to the service hook
> > As I can see (and sure that I'm wrong), I have the following alternatives
> of
> > processing SOAP headers:
> >  - using IN-wrappers:
> >  - override Application object customizing one of:
> >    - deserialize_soap (says: not meant to be override!)
> >    - decompose_incoming_envelope
> >    - process_request (says: not meant to be override!)
> > Where would be the best place to implement header checking? (e.g.
> security=
> > Thanks in advance.
> > Best regards.
> > Erny
> > Spain
> > Ernesto Revilla
> > Yaco Sistemas
> > +34 954 500 057
> >
> > _______________________________________________
> > 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/20110527/554a50a6/attachment-0001.html>

From erevilla at yaco.es  Fri May 27 02:08:14 2011
From: erevilla at yaco.es (Ernesto Revilla Derksen)
Date: Fri, 27 May 2011 02:08:14 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTinNpKw9-X3XMaq9A5+ogR3q+g+ymA@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
	<BANLkTikk5e3mb+=Q+-+chgi8zeb98_rmDg@mail.gmail.com>
	<BANLkTinNpKw9-X3XMaq9A5+ogR3q+g+ymA@mail.gmail.com>
Message-ID: <BANLkTimy8_=EDD0nLjRCRCUSQTi5QN0tUw@mail.gmail.com>

Another question.

2011/5/27 Ernesto Revilla Derksen <erevilla at yaco.es>

> Hi again.
>
> Now I am extracting de security data as follows (really easy!):
> ...
> ns_wsse = "
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
>
> class UsernameTokenType(ClassModel):
>     __namespace__ = ns_wsse
>     Username = String
>     Password = String
>     Nonce = String
>
I would like to add a datetime variable from another namespace (wsu). How
would I do that?

Erny


>
>
> class Security(ClassModel):
>     __namespace__ = ns_wsse
>     UsernameToken = UsernameTokenType
>
>
> class HelloWorldService(DefinitionBase):
>     __in_header__ = Security
>
>     def on_method_call(self, method_name, py_params, soap_params):
>         # I can't access self.in_header here!
>         pass
>
>     @soap(String, Integer, _returns=Array(String))
>     def say_hello(self, name, times):
>         # We have access to self.in_header here.
>         results = []
>         for i in range(0, times):
>             results.append('Hello, %s' % name)
>         return results
>
> To implement a service wide authentication procedure, I would have to
> implement it as decorator, as the method "on_method_call" has no access to
> "in_header".
>
> Any other suggestions?
>
> Regards.
> Erny
>
> 2011/5/27 Chris Austin <chris at sydneysys.com>
>
>> On Thu, May 26, 2011 at 5:16 PM, Ernesto Revilla Derksen
>> <erevilla at yaco.es> wrote:
>> > Hi.
>> > First of all, you're doing a great work with soaplib!!!
>> > I was just running the debugger to see how soaplibs treats the headers.
>> > In soaplib/core/_base.py:decompose_incoming_envelope (near line 335), we
>> get
>> > the header & body parsed. Fine!
>> > But just below, there is no self.validateHeader or self.checkHeader. So
>> the
>> > body is validated before (!) any headers can be validades. Could there
>> be a
>> > hook?
>> > In method deserialize_soap (lines 406-417):
>> >             # decode header object
>> >             if (ctx.in_header_xml is not None and
>> >                 len(ctx.in_header_xml) > 0 and
>> >                 header_class is not None):
>> >                 ctx.service.in_header =
>> > header_class.from_xml(ctx.in_header_xml)
>> >
>> > how do IN-wrappers supposed to work? could you give an example?
>>
>> Sure, this is taken from the test at
>>
>> https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/server/_service.py
>>
>> You can define your headers as follows.
>>
>> class InHeader(ClassModel):
>>    s=String
>>    i=Integer
>>
>> class OutHeader(ClassModel):
>>    dt=DateTime
>>    f=Float
>>
>> Now, you can write a service  that references your headers and, you
>> can get access to the headers in your web methods as echo_in_header()
>> and send_out_header() do below.
>>
>> class InteropServiceWithHeader(service.DefinitionBase):
>>    __in_header__ = InHeader
>>    __out_header__ = OutHeader
>>
>>    @soap(_returns=InHeader)
>>    def echo_in_header(self):
>>        return self.in_header
>>
>>    @soap(_returns=OutHeader)
>>    def send_out_header(self):
>>        self.out_header = OutHeader()
>>        self.out_header.dt = datetime(year=2000, month=01, day=01)
>>        self.out_header.f = 3.141592653
>>
>>        return self.out_header
>>
>>
>> Now, you can work with the headers in you client following something
>> similar to the following example which is also take from an interop
>> test found at :
>> https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/test_suds.py
>>
>> So, you can treat headers just like any other datatype exposed by the
>> service.
>>
>> def test_echo_in_header(self):
>>        in_header = self.client.factory.create('InHeader')
>>        in_header.s = 'a'
>>        in_header.i = 3
>>
>>        self.client.set_options(soapheaders=in_header)
>>        ret = self.client.service.echo_in_header()
>>        self.client.set_options(soapheaders=None)
>>
>>        print ret
>>
>>        self.assertEquals(in_header.s, ret.s)
>>        self.assertEquals(in_header.i, ret.i)
>>
>>    def test_send_out_header(self):
>>        out_header = self.client.factory.create('OutHeader')
>>        out_header.dt = datetime(year=2000, month=01, day=01)
>>        out_header.f = 3.141592653
>>
>>        ret = self.client.service.send_out_header()
>>
>>        self.assertTrue(isinstance(ret,type(out_header)))
>>        self.assertEquals(ret.dt, out_header.dt)
>>        self.assertEquals(ret.f, out_header.f)
>>
>>
>> I hope this helps.
>>
>> > In process_request (line 436):
>> > ctx.service.on_method_call(ctx.method_name,req_obj,ctx.in_body_xml)
>> > the header is NOT sent to the service hook
>> > As I can see (and sure that I'm wrong), I have the following
>> alternatives of
>> > processing SOAP headers:
>> >  - using IN-wrappers:
>> >  - override Application object customizing one of:
>> >    - deserialize_soap (says: not meant to be override!)
>> >    - decompose_incoming_envelope
>> >    - process_request (says: not meant to be override!)
>> > Where would be the best place to implement header checking? (e.g.
>> security=
>> > Thanks in advance.
>> > Best regards.
>> > Erny
>> > Spain
>> > Ernesto Revilla
>> > Yaco Sistemas
>> > +34 954 500 057
>> >
>> > _______________________________________________
>> > 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/20110527/fa4df5c1/attachment.html>

From burak.arslan at arskom.com.tr  Fri May 27 09:51:49 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 27 May 2011 10:51:49 +0300
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTimy8_=EDD0nLjRCRCUSQTi5QN0tUw@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>	<BANLkTikk5e3mb+=Q+-+chgi8zeb98_rmDg@mail.gmail.com>	<BANLkTinNpKw9-X3XMaq9A5+ogR3q+g+ymA@mail.gmail.com>
	<BANLkTimy8_=EDD0nLjRCRCUSQTi5QN0tUw@mail.gmail.com>
Message-ID: <4DDF5815.8030301@arskom.com.tr>

On 05/27/11 03:08, Ernesto Revilla Derksen wrote:
> Another question.
>
> 2011/5/27 Ernesto Revilla Derksen <erevilla at yaco.es
> <mailto:erevilla at yaco.es>>
>
>     Hi again.
>
>     Now I am extracting de security data as follows (really easy!):
>     ...
>     ns_wsse =
>     "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>
>     class UsernameTokenType(ClassModel):
>         __namespace__ = ns_wsse
>         Username = String
>         Password = String
>         Nonce = String
>
> I would like to add a datetime variable from another namespace (wsu).
> How would I do that?
>
> Erny

class WsuDateTime(DateTime):
    __namespace__ = ns_wsu

would do. however, if that's a different format (so the existing
DateTime serializers won't work) you should inherit from primitive.Base
and create a type from scratch.

class UsernameTokenType(ClassModel):
    (...)
    Date = WsuDateTime

>  
>
>
>
>     class Security(ClassModel):
>         __namespace__ = ns_wsse
>         UsernameToken = UsernameTokenType
>
>
>     class HelloWorldService(DefinitionBase):
>         __in_header__ = Security
>
>         def on_method_call(self, method_name, py_params, soap_params):
>             # I can't access self.in_header here!
>             pass
>
>         @soap(String, Integer, _returns=Array(String))
>         def say_hello(self, name, times):
>             # We have access to self.in_header here.
>             results = []
>             for i in range(0, times):
>                 results.append('Hello, %s' % name)
>             return results
>
>     To implement a service wide authentication procedure, I would have
>     to implement it as decorator, as the method "on_method_call" has
>     no access to "in_header".
>
>     Any other suggestions?
>

we need to add new hooks for you to be able to do that. it's not
possible with soaplib's current state.

best,
burak


>     Regards.
>     Erny
>
>     2011/5/27 Chris Austin <chris at sydneysys.com
>     <mailto:chris at sydneysys.com>>
>
>         On Thu, May 26, 2011 at 5:16 PM, Ernesto Revilla Derksen
>         <erevilla at yaco.es <mailto:erevilla at yaco.es>> wrote:
>         > Hi.
>         > First of all, you're doing a great work with soaplib!!!
>         > I was just running the debugger to see how soaplibs treats
>         the headers.
>         > In soaplib/core/_base.py:decompose_incoming_envelope (near
>         line 335), we get
>         > the header & body parsed. Fine!
>         > But just below, there is no self.validateHeader or
>         self.checkHeader. So the
>         > body is validated before (!) any headers can be validades.
>         Could there be a
>         > hook?
>         > In method deserialize_soap (lines 406-417):
>         >             # decode header object
>         >             if (ctx.in_header_xml is not None and
>         >                 len(ctx.in_header_xml) > 0 and
>         >                 header_class is not None):
>         >                 ctx.service.in_header =
>         > header_class.from_xml(ctx.in_header_xml)
>         >
>         > how do IN-wrappers supposed to work? could you give an example?
>
>         Sure, this is taken from the test at
>         https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/server/_service.py
>
>         You can define your headers as follows.
>
>         class InHeader(ClassModel):
>            s=String
>            i=Integer
>
>         class OutHeader(ClassModel):
>            dt=DateTime
>            f=Float
>
>         Now, you can write a service  that references your headers
>         and, you
>         can get access to the headers in your web methods as
>         echo_in_header()
>         and send_out_header() do below.
>
>         class InteropServiceWithHeader(service.DefinitionBase):
>            __in_header__ = InHeader
>            __out_header__ = OutHeader
>
>            @soap(_returns=InHeader)
>            def echo_in_header(self):
>                return self.in_header
>
>            @soap(_returns=OutHeader)
>            def send_out_header(self):
>                self.out_header = OutHeader()
>                self.out_header.dt = datetime(year=2000, month=01, day=01)
>                self.out_header.f = 3.141592653
>
>                return self.out_header
>
>
>         Now, you can work with the headers in you client following
>         something
>         similar to the following example which is also take from an
>         interop
>         test found at
>         :https://github.com/soaplib/soaplib/blob/master/src/soaplib/core/test/interop/test_suds.py
>
>         So, you can treat headers just like any other datatype exposed
>         by the service.
>
>         def test_echo_in_header(self):
>                in_header = self.client.factory.create('InHeader')
>                in_header.s = 'a'
>                in_header.i = 3
>
>                self.client.set_options(soapheaders=in_header)
>                ret = self.client.service.echo_in_header()
>                self.client.set_options(soapheaders=None)
>
>                print ret
>
>                self.assertEquals(in_header.s, ret.s)
>                self.assertEquals(in_header.i, ret.i)
>
>            def test_send_out_header(self):
>                out_header = self.client.factory.create('OutHeader')
>                out_header.dt = datetime(year=2000, month=01, day=01)
>                out_header.f = 3.141592653
>
>                ret = self.client.service.send_out_header()
>
>                self.assertTrue(isinstance(ret,type(out_header)))
>                self.assertEquals(ret.dt, out_header.dt)
>                self.assertEquals(ret.f, out_header.f)
>
>
>         I hope this helps.
>
>         > In process_request (line 436):
>         >
>         ctx.service.on_method_call(ctx.method_name,req_obj,ctx.in_body_xml)
>         > the header is NOT sent to the service hook
>         > As I can see (and sure that I'm wrong), I have the following
>         alternatives of
>         > processing SOAP headers:
>         >  - using IN-wrappers:
>         >  - override Application object customizing one of:
>         >    - deserialize_soap (says: not meant to be override!)
>         >    - decompose_incoming_envelope
>         >    - process_request (says: not meant to be override!)
>         > Where would be the best place to implement header checking?
>         (e.g. security=
>         > Thanks in advance.
>         > Best regards.
>         > Erny
>         > Spain
>         > Ernesto Revilla
>         > Yaco Sistemas
>         > +34 954 500 057
>         >
>         > _______________________________________________
>         > 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
> http://mail.python.org/mailman/listinfo/soap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110527/32141f5a/attachment-0001.html>

From dsuch at gefira.pl  Fri May 27 10:03:53 2011
From: dsuch at gefira.pl (Dariusz Suchojad)
Date: Fri, 27 May 2011 10:03:53 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
Message-ID: <4DDF5AE9.7080300@gefira.pl>

Ernesto Revilla Derksen wrote:

Hello,

> Where would be the best place to implement header checking? (e.g. security=

[...]

just wanted to add something and say that what you're looking for, the 
username/token profile, has already been done in sec-wall, the security 
proxy. So if you can simply install a dedicated piece of software 
instead of re-implementing it from scratch then I guess you will find 
sec-wall just the thing for the job.

http://sec-wall.gefira.pl/index.html

http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passwordtext.html

http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passworddigest.html

And in case you prefer to do it all yourself you can have a look at its 
implementation and test cases at

http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/src/secwall/wsse.py

http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/tests/test_wsse.py

cheers,

-- 
Dariusz Suchojad

From burak.arslan at arskom.com.tr  Fri May 27 12:45:18 2011
From: burak.arslan at arskom.com.tr (Burak Arslan)
Date: Fri, 27 May 2011 13:45:18 +0300
Subject: [Soap-Python] new release: rpclib-1.2.1 with static calls and
 patches from soaplib. thoughts on rpclib-1.3.0?
Message-ID: <4DDF80BE.80601@arskom.com.tr>

Hi,

I've just released rpclib-1.2.1. The most notable change is static
methods via the @srpc decorator, apart from what soaplib team did during
the past 6 months.

The methods decorated with @rpc are also static, but get a first
argument as method context. it's not a class you're supposed to
subclass. Instead, you should move your custom context initialization in
on_method_call or call_wrapper hooks. Rule of thumb: use on_method_call
to initialize your context, and use call_wrapper to customize exception
handling.

I'm planning to replace hooks with events for the next release. For example:

def on_method_call_handler(ctx):
    ctx.db_conn = DatabaseConnection(ctx.app.database_connection_string)

BlahServiceDefinition.add_listener('on_method_call', on_method_call_handler)

This will make the interface more flexible, and make way for rpclib to
support async events natively.

Any feedback on that?

Best,
Burak

ps: documentation is completely out-of-date. bear with me.



From erevilla at yaco.es  Fri May 27 19:23:03 2011
From: erevilla at yaco.es (Ernesto Revilla Derksen)
Date: Fri, 27 May 2011 19:23:03 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <4DDF5AE9.7080300@gefira.pl>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
	<4DDF5AE9.7080300@gefira.pl>
Message-ID: <BANLkTi=VqdfN6gHsb=AEEjqjAzr1FrNFBw@mail.gmail.com>

Hi.

2011/5/27 Dariusz Suchojad <dsuch at gefira.pl>

> Ernesto Revilla Derksen wrote:
>
> Hello,
>
>
>  Where would be the best place to implement header checking? (e.g.
>> security=
>>
>
> [...]
>
> just wanted to add something and say that what you're looking for, the
> username/token profile, has already been done in sec-wall, the security
> proxy. So if you can simply install a dedicated piece of software instead of
> re-implementing it from scratch then I guess you will find sec-wall just the
> thing for the job.
>
> http://sec-wall.gefira.pl/index.html
>
>
> http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passwordtext.html
>
>
> http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passworddigest.html
>
> And in case you prefer to do it all yourself you can have a look at its
> implementation and test cases at
>
>
> http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/src/secwall/wsse.py
>
>
> http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/tests/test_wsse.py
>
> cheers,
>

Great, thanks for the info. I'm not sure I want to add just another system
before my webservices, but it's, of course, a good option.

I'll have a look. I'll check if it has support for SAML tokens, that's what
I'm really interested in.

Regards.
Erny



>
> --
> Dariusz Suchojad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20110527/14b17841/attachment.html>

From dsuch at gefira.pl  Fri May 27 19:30:15 2011
From: dsuch at gefira.pl (Dariusz Suchojad)
Date: Fri, 27 May 2011 19:30:15 +0200
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
In-Reply-To: <BANLkTi=VqdfN6gHsb=AEEjqjAzr1FrNFBw@mail.gmail.com>
References: <BANLkTinvRFb-wn0Y7qGVPY3cvqss_+fLaA@mail.gmail.com>
	<4DDF5AE9.7080300@gefira.pl>
	<BANLkTi=VqdfN6gHsb=AEEjqjAzr1FrNFBw@mail.gmail.com>
Message-ID: <4DDFDFA7.5030807@gefira.pl>

Ernesto Revilla Derksen wrote:

> Great, thanks for the info. I'm not sure I want to add just another system
> before my webservices, but it's, of course, a good option.

Sure, great!

> I'll have a look. I'll check if it has support for SAML tokens, that's what
> I'm really interested in.

Nope, it doesn't but if you'd be so kind to let me know about your
specific needs at the bug tracker https://launchpad.net/sec-wall then
I'm sure we can arrange something :-) Of course, not necessarily now,
whenever it's most convenient for you. Maybe next time you're be looking
for something like that.

cheers,

-- 
Dariusz Suchojad

From chris at sydneysys.com  Sat May 28 02:54:19 2011
From: chris at sydneysys.com (Sydneysys)
Date: Fri, 27 May 2011 19:54:19 -0500
Subject: [Soap-Python] soaplib: Some additional hooks for header
 processing (aka ws-security, etc.)
Message-ID: <gb0llyio3310c7j9b12mr49e.1306543788160@email.android.com>

Have you looked into pysaml2 https://code.launchpad.net/pysaml2?  

Ernesto Revilla Derksen <erevilla at yaco.es> wrote:

>Hi.
>
>2011/5/27 Dariusz Suchojad <dsuch at gefira.pl>
>
>> Ernesto Revilla Derksen wrote:
>>
>> Hello,
>>
>>
>>  Where would be the best place to implement header checking? (e.g.
>>> security=
>>>
>>
>> [...]
>>
>> just wanted to add something and say that what you're looking for, the
>> username/token profile, has already been done in sec-wall, the security
>> proxy. So if you can simply install a dedicated piece of software instead of
>> re-implementing it from scratch then I guess you will find sec-wall just the
>> thing for the job.
>>
>> http://sec-wall.gefira.pl/index.html
>>
>>
>> http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passwordtext.html
>>
>>
>> http://sec-wall.gefira.pl/documentation/usage-examples/ws-security-passworddigest.html
>>
>> And in case you prefer to do it all yourself you can have a look at its
>> implementation and test cases at
>>
>>
>> http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/src/secwall/wsse.py
>>
>>
>> http://bazaar.launchpad.net/~sec-wall-dev/sec-wall/trunk/view/head:/code/tests/test_wsse.py
>>
>> cheers,
>>
>
>Great, thanks for the info. I'm not sure I want to add just another system
>before my webservices, but it's, of course, a good option.
>
>I'll have a look. I'll check if it has support for SAML tokens, that's what
>I'm really interested in.
>
>Regards.
>Erny
>
>
>
>>
>> --
>> Dariusz Suchojad
>>
>
>_______________________________________________
>Soap mailing list
>Soap at python.org
>http://mail.python.org/mailman/listinfo/soap