From misc8 at emerose.org Fri Jun 4 05:54:28 2010 From: misc8 at emerose.org (Ben Escoto) Date: Thu, 3 Jun 2010 22:54:28 -0500 Subject: [Soap-Python] current soaplib tarball? Message-ID: <20100603225428.67542e56.misc8@emerose.org> Hi all, I'm trying to setup a server using soaplib. After running into a few problems, I did some web searching and it appears that the soaplib issue tracker, code repository, and mailing list is in a state of flux. I tried getting the newest sources, but they didn't seem to contain some of the fixes I've read on the issue tracker or on mailing lists. Can someone familiar with soaplib please make an updated tarball for me that contains known fixes? I'd really like to make sure I'm using the best version---because I'm new to SOAP any interoperability issues will be very frustrating for me. Thank you very much, -- Ben Escoto From burak.arslan at arskom.com.tr Wed Jun 9 13:59:27 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 09 Jun 2010 14:59:27 +0300 Subject: [Soap-Python] recent pushes to jkp/soaplib Message-ID: <4C0F821F.3030701@arskom.com.tr> Hi, I've taken time to merge the most recent fixes into Jamie's repository. We've been using very similar code in production for some time now, and code review and limited testing shows no sign of trouble, so I think we're good for a release. Please test especially the client code and the new primitives Date, Optional, Decimal and chime in with your results. I'll push my version of soaplib soon. It breaks api compatibility with existing soaplib, in an effort to be compatible with sqlalchemy's declarative; so that one will be able to return table objects without any duplication of effort. It is experimental yet compact and seems to get the basics right. I'm interested in feedback and patches. I'll also remove non-server parts from the distribution. One last bit; You might remember me talking about aiming one single soap serializer-deserializer library. Suds was the prime candidate, but preliminary tests show that its sax-based engine is very slow compared to the soaplib's lxml based one. Maybe someone would take time to publish a pseudo-scientific experiments about both engines' performance. So, I am now a bit more sceptical about that prospect. Best Regards, Burak From misc8 at emerose.org Wed Jun 9 14:58:47 2010 From: misc8 at emerose.org (Ben Escoto) Date: Wed, 9 Jun 2010 07:58:47 -0500 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: <4C0F821F.3030701@arskom.com.tr> References: <4C0F821F.3030701@arskom.com.tr> Message-ID: <20100609075847.c97bdaec.misc8@emerose.org> Great, thanks Burak. I've been using your fork from github which has worked much better for me than the default version, so it'll be good to see those changes consolidated. That version is compatible with Microsoft's Web Services Toolkit, which is my main target, but strangely suds didn't like even simple cases. Anyway, I'll upgrade to this merged soaplib and the newest suds and see if it works. Thanks, -- Ben Escoto ----------------- Original message ----------------- From: Burak Arslan To: soap at python.org Date: Wed, 09 Jun 2010 14:59:27 +0300 Hi, I've taken time to merge the most recent fixes into Jamie's repository. We've been using very similar code in production for some time now, and code review and limited testing shows no sign of trouble, so I think we're good for a release. Please test especially the client code and the new primitives Date, Optional, Decimal and chime in with your results. I'll push my version of soaplib soon. It breaks api compatibility with existing soaplib, in an effort to be compatible with sqlalchemy's declarative; so that one will be able to return table objects without any duplication of effort. It is experimental yet compact and seems to get the basics right. I'm interested in feedback and patches. I'll also remove non-server parts from the distribution. One last bit; You might remember me talking about aiming one single soap serializer-deserializer library. Suds was the prime candidate, but preliminary tests show that its sax-based engine is very slow compared to the soaplib's lxml based one. Maybe someone would take time to publish a pseudo-scientific experiments about both engines' performance. So, I am now a bit more sceptical about that prospect. Best Regards, Burak _______________________________________________ Soap mailing list Soap at python.org http://mail.python.org/mailman/listinfo/soap From jkp at kirkconsulting.co.uk Wed Jun 9 15:10:17 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Wed, 9 Jun 2010 14:10:17 +0100 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: <20100609075847.c97bdaec.misc8@emerose.org> References: <4C0F821F.3030701@arskom.com.tr> <20100609075847.c97bdaec.misc8@emerose.org> Message-ID: Thanks Burak...good work pushing to the main repo. Should we do a release to PyPi soon? -- Jamie Kirkpatrick 07818 422311 On 9 June 2010 13:58, Ben Escoto wrote: > Great, thanks Burak. I've been using your fork from github which has > worked much better for me than the default version, so it'll be good > to see those changes consolidated. That version is compatible with > Microsoft's Web Services Toolkit, which is my main target, but > strangely suds didn't like even simple cases. Anyway, I'll upgrade to > this merged soaplib and the newest suds and see if it works. > > Thanks, > > -- > Ben Escoto > > ----------------- Original message ----------------- > From: Burak Arslan > To: soap at python.org > Date: Wed, 09 Jun 2010 14:59:27 +0300 > Hi, > > I've taken time to merge the most recent fixes into Jamie's repository. > We've been using very similar code in production for some time now, and > code review and limited testing shows no sign of trouble, so I think > we're good for a release. > > Please test especially the client code and the new primitives Date, > Optional, Decimal and chime in with your results. > > I'll push my version of soaplib soon. It breaks api compatibility with > existing soaplib, in an effort to be compatible with sqlalchemy's > declarative; so that one will be able to return table objects without > any duplication of effort. It is experimental yet compact and seems to > get the basics right. I'm interested in feedback and patches. > > I'll also remove non-server parts from the distribution. > > One last bit; You might remember me talking about aiming one single soap > serializer-deserializer library. Suds was the prime candidate, but > preliminary tests show that its sax-based engine is very slow compared > to the soaplib's lxml based one. Maybe someone would take time to > publish a pseudo-scientific experiments about both engines' performance. > So, I am now a bit more sceptical about that prospect. > > Best Regards, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Wed Jun 9 17:57:48 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 09 Jun 2010 18:57:48 +0300 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: References: <4C0F821F.3030701@arskom.com.tr> <20100609075847.c97bdaec.misc8@emerose.org> Message-ID: <4C0FB9FC.6070001@arskom.com.tr> On 06/09/10 16:10, Jamie Kirkpatrick wrote: > Thanks Burak...good work pushing to the main repo. > > Should we do a release to PyPi soon? > Hi Jamie, I think the current state of your master branch could be tagged as 0.8.2alpha -- so it's a bit early for a pypi release. The documentation looks fabulous btw :) Best Regards, Burak From bradallen137 at gmail.com Wed Jun 9 18:01:33 2010 From: bradallen137 at gmail.com (Brad Allen) Date: Wed, 9 Jun 2010 11:01:33 -0500 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: References: <4C0F821F.3030701@arskom.com.tr> <20100609075847.c97bdaec.misc8@emerose.org> Message-ID: We might want to increment the major version, if this is a public API change which breaks backward compatibility. I like the Semantic Versioning guidelines at semver.org; it very clear guidelines about how to manage version increments based on the nature of changes to the public API. This helps consumers of the package stay out of dependency hell, and know when it's safe or unsafe to upgrade. The Semantic Versioning guidelines also urge keeping API documentation complete and current, so that it's always crystal clear when the public API changes. I'm sorry I've lagged behind a bit working on this, but hope to do a bit more work soon (I want to use the new Sphinx 1.0 beta which allows bringing in docstrings and links to source code). On Wed, Jun 9, 2010 at 8:10 AM, Jamie Kirkpatrick wrote: > Thanks Burak...good work pushing to the main repo. > Should we do a release to PyPi soon? > > -- > Jamie Kirkpatrick > 07818 422311 > > On 9 June 2010 13:58, Ben Escoto wrote: >> >> Great, thanks Burak. ?I've been using your fork from github which has >> worked much better for me than the default version, so it'll be good >> to see those changes consolidated. ?That version is compatible with >> Microsoft's Web Services Toolkit, which is my main target, but >> strangely suds didn't like even simple cases. ?Anyway, I'll upgrade to >> this merged soaplib and the newest suds and see if it works. >> >> Thanks, >> >> -- >> Ben Escoto >> >> ----------------- Original message ----------------- >> From: Burak Arslan >> To: soap at python.org >> Date: Wed, 09 Jun 2010 14:59:27 +0300 >> Hi, >> >> I've taken time to merge the most recent fixes into Jamie's repository. >> We've been using very similar code in production for some time now, and >> code review and limited testing shows no sign of trouble, so I think >> we're good for a release. >> >> Please test especially the client code and the new primitives Date, >> Optional, Decimal and chime in with your results. >> >> I'll push my version of soaplib soon. It breaks api compatibility with >> existing soaplib, in an effort to be compatible with sqlalchemy's >> declarative; so that one will be able to return table objects without >> any duplication of effort. It is experimental yet compact and seems to >> get the basics right. I'm interested in feedback and patches. >> >> I'll also remove non-server parts from the distribution. >> >> One last bit; You might remember me talking about aiming one single soap >> serializer-deserializer library. Suds was the prime candidate, but >> preliminary tests show that its sax-based engine is very slow compared >> to the soaplib's lxml based one. Maybe someone would take time to >> publish a pseudo-scientific experiments about both engines' performance. >> So, I am now a bit more sceptical about that prospect. >> >> Best Regards, >> 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 > > From bradallen137 at gmail.com Wed Jun 9 18:04:13 2010 From: bradallen137 at gmail.com (Brad Allen) Date: Wed, 9 Jun 2010 11:04:13 -0500 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: References: <4C0F821F.3030701@arskom.com.tr> <20100609075847.c97bdaec.misc8@emerose.org> Message-ID: On Wed, Jun 9, 2010 at 11:01 AM, Brad Allen wrote: > We might want to increment the major version, if this is a public API > change which breaks backward compatibility. Except I just realized if we follow the Semantic Versioning rules, there is an exception for the 0.x versions: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." We're still in a 0.x version for soaplib, so I guess that applies. From jkp at kirkconsulting.co.uk Wed Jun 9 18:54:07 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Wed, 9 Jun 2010 17:54:07 +0100 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: References: <4C0F821F.3030701@arskom.com.tr> <20100609075847.c97bdaec.misc8@emerose.org> Message-ID: Great link (semantic versioning). I've banged a few heads together in the day job with that one. -- Jamie Kirkpatrick 07818 422311 On 9 June 2010 17:01, Brad Allen wrote: > We might want to increment the major version, if this is a public API > change which breaks backward compatibility. > > I like the Semantic Versioning guidelines at semver.org; it very clear > guidelines about how to manage version increments based on the nature > of changes to the public API. This helps consumers of the package stay > out of dependency hell, and know when it's safe or unsafe to upgrade. > > The Semantic Versioning guidelines also urge keeping API documentation > complete and current, so that it's always crystal clear when the > public API changes. I'm sorry I've lagged behind a bit working on > this, but hope to do a bit more work soon (I want to use the new > Sphinx 1.0 beta which allows bringing in docstrings and links to > source code). > > On Wed, Jun 9, 2010 at 8:10 AM, Jamie Kirkpatrick > wrote: > > Thanks Burak...good work pushing to the main repo. > > Should we do a release to PyPi soon? > > > > -- > > Jamie Kirkpatrick > > 07818 422311 > > > > On 9 June 2010 13:58, Ben Escoto wrote: > >> > >> Great, thanks Burak. I've been using your fork from github which has > >> worked much better for me than the default version, so it'll be good > >> to see those changes consolidated. That version is compatible with > >> Microsoft's Web Services Toolkit, which is my main target, but > >> strangely suds didn't like even simple cases. Anyway, I'll upgrade to > >> this merged soaplib and the newest suds and see if it works. > >> > >> Thanks, > >> > >> -- > >> Ben Escoto > >> > >> ----------------- Original message ----------------- > >> From: Burak Arslan > >> To: soap at python.org > >> Date: Wed, 09 Jun 2010 14:59:27 +0300 > >> Hi, > >> > >> I've taken time to merge the most recent fixes into Jamie's repository. > >> We've been using very similar code in production for some time now, and > >> code review and limited testing shows no sign of trouble, so I think > >> we're good for a release. > >> > >> Please test especially the client code and the new primitives Date, > >> Optional, Decimal and chime in with your results. > >> > >> I'll push my version of soaplib soon. It breaks api compatibility with > >> existing soaplib, in an effort to be compatible with sqlalchemy's > >> declarative; so that one will be able to return table objects without > >> any duplication of effort. It is experimental yet compact and seems to > >> get the basics right. I'm interested in feedback and patches. > >> > >> I'll also remove non-server parts from the distribution. > >> > >> One last bit; You might remember me talking about aiming one single soap > >> serializer-deserializer library. Suds was the prime candidate, but > >> preliminary tests show that its sax-based engine is very slow compared > >> to the soaplib's lxml based one. Maybe someone would take time to > >> publish a pseudo-scientific experiments about both engines' performance. > >> So, I am now a bit more sceptical about that prospect. > >> > >> Best Regards, > >> 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: From joshua at eeinternet.com Wed Jun 9 19:33:29 2010 From: joshua at eeinternet.com (Joshua J. Kugler) Date: Wed, 9 Jun 2010 09:33:29 -0800 Subject: [Soap-Python] recent pushes to jkp/soaplib Message-ID: <201006090933.30296.joshua@eeinternet.com> [Resending because I didn't see this on the list or in the archives, and received no notice of it being held for moderation.] On Wednesday 09 June 2010, Burak Arslan elucidated thus: > One last bit; You might remember me talking about aiming one single > soap serializer-deserializer library. Suds was the prime candidate, > but preliminary tests show that its sax-based engine is very slow > compared to the soaplib's lxml based one. Maybe someone would take > time to publish a pseudo-scientific experiments about both engines' > performance. So, I am now a bit more sceptical about that prospect. It's very possible that the sax based engine in Suds is a bit non-optimized. From the docs: "The suds.sax module was written becuase elementtree and other python XML packages either: have a DOM API which is very unfriendly or: (in the case of elementtree) do not deal with namespaces and especially prefixes sufficiently." If a thin sax-like wrapper could be written around lxml, that might be a possibility for suds, speeding it up a good deal. I do know that Suds is *very* easy to work with, and does a great job turning SOAP responses into Python data structures. j -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ?ID 0x73B13B6A From bradallen137 at gmail.com Wed Jun 9 20:43:50 2010 From: bradallen137 at gmail.com (Brad Allen) Date: Wed, 9 Jun 2010 13:43:50 -0500 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: <4C0F821F.3030701@arskom.com.tr> References: <4C0F821F.3030701@arskom.com.tr> Message-ID: On Wed, Jun 9, 2010 at 6:59 AM, Burak Arslan wrote: > I'll push my version of soaplib soon. It breaks api compatibility with > existing soaplib, in an effort to be compatible with sqlalchemy's > declarative; so that one will be able to return table objects without > any duplication of effort. It is experimental yet compact and seems to > get the basics right. I'm interested in feedback and patches. I'm wondering if there is any reason this should not be handled as a branch instead of a fork. Right now there is only a master branch of soaplib, but one of the big benefits of using Git is the convenience of working with branches. I'd like to suggest we consider the master branch to be a release branch, and only merge changes into master when it's time for a new release. The mainline of work toward the current release could happen in a branch called 'development'. If we need to maintain older releases, we could put those in maintenance branches named after major+minor version numbers, like 'maint_0.8'. Fixes to old releases could be put in release branches named like 'release_0.8'. Collectively release and development branches (for both current and maintenance) could be termed "integration branches". The goal would be to eventually get all the integration branches running on a continuous integration server, and set an expectation that nobody should push to those integration branches until all tests are passing. However, we can also have some branches which are not considered integration branches. For example, specific enhancements or bugfixes could go into "topic branches" named based on the nature of the change. These kinds of branches would fall under scrutiny for review before getting merged into an integration branch. Also, topic branches might be prefixed with the name or initials of the developer, to make it clear who is responsible for that branch. We've just started following this approach at my day job, and to me it makes a lot of sense. It's the kind of thing that was very awkward to manage under Svn but Git naturally encourages. From joshua at eeinternet.com Wed Jun 9 18:48:55 2010 From: joshua at eeinternet.com (Joshua J. Kugler) Date: Wed, 9 Jun 2010 08:48:55 -0800 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: <4C0F821F.3030701@arskom.com.tr> References: <4C0F821F.3030701@arskom.com.tr> Message-ID: <201006090848.56079.joshua@eeinternet.com> On Wednesday 09 June 2010, Burak Arslan elucidated thus: > One last bit; You might remember me talking about aiming one single > soap serializer-deserializer library. Suds was the prime candidate, > but preliminary tests show that its sax-based engine is very slow > compared to the soaplib's lxml based one. Maybe someone would take > time to publish a pseudo-scientific experiments about both engines' > performance. So, I am now a bit more sceptical about that prospect. It's very possible that the sax based engine in Suds is a bit non-optimized. From the docs: "The suds.sax module was written becuase elementtree and other python XML packages either: have a DOM API which is very unfriendly or: (in the case of elementtree) do not deal with namespaces and especially prefixes sufficiently." If a thin sax-like wrapper could be written around lxml, that might be a possibility for suds, speeding it up a good deal. I do know that Suds is *very* easy to work with, and does a great job turning SOAP responses into Python data structures. j -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ?ID 0x73B13B6A From burak.arslan at arskom.com.tr Thu Jun 10 09:54:01 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Thu, 10 Jun 2010 10:54:01 +0300 Subject: [Soap-Python] copyright notices Message-ID: <4C109A19.3020508@arskom.com.tr> All, The list of contributors to soaplib seem to be growing. It's starting to become impractical to maintain the list in the headers of the source files. I suggest changing all headers so: # soaplib - Copyright (C) soaplib contributors and adding a CONTRIBUTORS file to the package root listing names. What do you think? Burak From jkp at kirkconsulting.co.uk Thu Jun 10 10:05:01 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Thu, 10 Jun 2010 09:05:01 +0100 Subject: [Soap-Python] copyright notices In-Reply-To: <4C109A19.3020508@arskom.com.tr> References: <4C109A19.3020508@arskom.com.tr> Message-ID: Sounds good. -- Jamie Kirkpatrick 07818 422311 On 10 June 2010 08:54, Burak Arslan wrote: > All, > > The list of contributors to soaplib seem to be growing. It's starting to > become impractical to maintain the list in the headers of the source files. > > I suggest changing all headers so: > > # soaplib - Copyright (C) soaplib contributors > > and adding a CONTRIBUTORS file to the package root listing names. > > What do you think? > > Burak > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arbitraryuser at gmail.com Thu Jun 10 10:56:14 2010 From: arbitraryuser at gmail.com (Jonathan Endersby) Date: Thu, 10 Jun 2010 10:56:14 +0200 Subject: [Soap-Python] soaplib "landing" page and documentation. Message-ID: Hi A couple of things: 1. The page that currently ranks highest in google for "soaplib" is "wiki.github.com/jkp/soaplib/" which is currently out of date. 2. The new Sphinx'ified documentation is visible at the bottom of "http://github.com/jkp/soaplib" which doesn't seem intuitive. How/where is the documentation supposed to exist? What page should be the "landing page" for the project? Regards j. On 10 June 2010 10:05, Jamie Kirkpatrick wrote: > Sounds good. > > -- > Jamie Kirkpatrick > 07818 422311 > > On 10 June 2010 08:54, Burak Arslan wrote: >> >> All, >> >> The list of contributors to soaplib seem to be growing. It's starting to >> become impractical to maintain the list in the headers of the source >> files. >> >> I suggest changing all headers so: >> >> # soaplib - Copyright (C) soaplib contributors >> >> and adding a CONTRIBUTORS file to the package root listing names. >> >> What do you think? >> >> 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 > > -- Jonathan Endersby Connect. Share. Trust. www.trustfabric.com +27 82 414 3129 www.arbitraryuser.com tfid: arbitraryuser You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. - Dr Seuss From arbitraryuser at gmail.com Thu Jun 10 11:15:32 2010 From: arbitraryuser at gmail.com (Jonathan Endersby) Date: Thu, 10 Jun 2010 11:15:32 +0200 Subject: [Soap-Python] soaplib "landing" page and documentation. In-Reply-To: References: Message-ID: Hi On 10 June 2010 10:56, Jonathan Endersby wrote: > 1. The page that currently ranks highest in google for "soaplib" is > "wiki.github.com/jkp/soaplib/" which is currently out of date. I've made a few changes to the wiki to point to the new documentation and added in a few dates so that it's obvious the project is active. J. From jkp at kirkconsulting.co.uk Thu Jun 10 11:32:27 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Thu, 10 Jun 2010 10:32:27 +0100 Subject: [Soap-Python] soaplib "landing" page and documentation. In-Reply-To: References: Message-ID: Thanks Jonathan. I've tweaked the documentation on the landing page to reference lxml rather than ElementTree which is not used any more. -- Jamie Kirkpatrick 07818 422311 On 10 June 2010 10:15, Jonathan Endersby wrote: > Hi > > On 10 June 2010 10:56, Jonathan Endersby wrote: > > 1. The page that currently ranks highest in google for "soaplib" is > > "wiki.github.com/jkp/soaplib/" which is currently out of date. > > I've made a few changes to the wiki to point to the new documentation > and added in a few dates so that it's obvious the project is active. > > J. > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkp at kirkconsulting.co.uk Thu Jun 10 11:40:52 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Thu, 10 Jun 2010 10:40:52 +0100 Subject: [Soap-Python] recent pushes to jkp/soaplib In-Reply-To: References: <4C0F821F.3030701@arskom.com.tr> Message-ID: Could you put this together as a proposal on the wiki? We can then all edit and tweak it until we agree a policy and it will then be there for reference to ensure people know what to do. -- Jamie Kirkpatrick 07818 422311 On 9 June 2010 19:43, Brad Allen wrote: > On Wed, Jun 9, 2010 at 6:59 AM, Burak Arslan > wrote: > > > I'll push my version of soaplib soon. It breaks api compatibility with > > existing soaplib, in an effort to be compatible with sqlalchemy's > > declarative; so that one will be able to return table objects without > > any duplication of effort. It is experimental yet compact and seems to > > get the basics right. I'm interested in feedback and patches. > > I'm wondering if there is any reason this should not be handled as a > branch instead of a fork. Right now there is only a master branch of > soaplib, but one of the big benefits of using Git is the convenience > of working with branches. > > I'd like to suggest we consider the master branch to be a release > branch, and only merge changes into master when it's time for a new > release. > > The mainline of work toward the current release could happen in a > branch called 'development'. > > If we need to maintain older releases, we could put those in > maintenance branches named after major+minor version numbers, like > 'maint_0.8'. Fixes to old releases could be put in release branches > named like 'release_0.8'. > > Collectively release and development branches (for both current and > maintenance) could be termed "integration branches". The goal would be > to eventually get all the integration branches running on a continuous > integration server, and set an expectation that nobody should push to > those integration branches until all tests are passing. > > However, we can also have some branches which are not considered > integration branches. For example, specific enhancements or bugfixes > could go into "topic branches" named based on the nature of the > change. These kinds of branches would fall under scrutiny for review > before getting merged into an integration branch. Also, topic branches > might be prefixed with the name or initials of the developer, to make > it clear who is responsible for that branch. > > We've just started following this approach at my day job, and to me it > makes a lot of sense. It's the kind of thing that was very awkward to > manage under Svn but Git naturally encourages. > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arbitraryuser at gmail.com Thu Jun 10 11:51:33 2010 From: arbitraryuser at gmail.com (Jonathan Endersby) Date: Thu, 10 Jun 2010 11:51:33 +0200 Subject: [Soap-Python] Changelog since 0.8.1 Message-ID: Hi I haven't switched to the dev version simply because I'm too scared.... Is there a changelog somewhere with the biggest bits to look at? j. -- Jonathan Endersby From burak.arslan at arskom.com.tr Sun Jun 20 23:47:42 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Mon, 21 Jun 2010 00:47:42 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib Message-ID: <4C1E8C7E.2040002@arskom.com.tr> hi, i've recently committed a large diff to my own repo. the most important point is that nothing is working yet. some less important points, in no particular order, follow: 1) the class/instance inconsistency is gone. Before: class NotSoComplexType(ClassSerializer): class types: a=Integer class ComplexType(ClassSerializer): class types: a=Array(String) # <- instance b=String # <- class c=NotSoComplexType # <- class after: class ComplexType(ClassSerializer): a=Array(String) # <- class b=String # <- class c=NotSoComplexType # <- class Primitive classes' __new__ is overridden to return a *copy* of the original class definition instead of an *instance* of the original class definition. However: class ComplexType(ClassSerializer): a=Array(String) # <- class b=String # <- class c=NotSoComplexType() # <- instance. don't do this! Instead: class ComplexType(ClassSerializer): a=Array(String) # <- class b=String # <- class c=NotSoComplexType.customize(whatever="punk") # <- class why would you need that? for example: email = String.customize(regex=r'[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not supported yet.) as I said above, with primitives, there's a shortcut: email = String(regex='[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not supported yet.) This statement implicitly calls customize, and produces a new String type on the fly. (maybe the word customize is too long?) 2) @soapmethod is renamed to @rpc 3) xml and etimport modules are gone, nsmap is now just a python dict. get_datatype and friends are gone. you can use get_type_name and get_type_name_ns methods. soaplib.get_namespace_prefix(namespace) manages the namespaces and prefixes automatically. from lxml import etree parent = etree.Element("{%s}parent % namespace) child = etree.SubElement(parent, "{%s}child" % namespace) is what we do now. 5) CamelCase is only used for class names. anything else has underscores_separating_words. 6) Multiple namespaces are (will be) supported. Before: import m1 import m2 class ComplexObject(ClassSerializer): class types: a=m1.Punk b=m2.Punk m1.Punk was overwritten by m2.Punk (or vice versa). After: Separate tags are inserted for each python namespace. Currently it is not working because there are no tags inside tags. first thing to do once I get some time. 7) thanks to better modularization of serializers.primitive module, a nice chunk of duplicate code was removed. 8) hooks api was updated. as said above, camelCase is gone. additionally, on_results takes an additional argument to let you modify http headers. 9) python's logging module is now used. debug statements should be ignored when not debugging. fwiw, these are mostly to scratch my own itches. awaiting your feedback. please help with documentation! best, burak From jkp at kirkconsulting.co.uk Mon Jun 21 19:50:50 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Mon, 21 Jun 2010 18:50:50 +0100 Subject: [Soap-Python] recent pushes to plq/soaplib In-Reply-To: <4C1E8C7E.2040002@arskom.com.tr> References: <4C1E8C7E.2040002@arskom.com.tr> Message-ID: Hi Burak Thanks very much for the updates. I have some thoughts reading back what you've said but they aren't very fully formed :) 1) the class/instance inconsistency is gone. Great, definitely makes sense. > > c=NotSoComplexType.customize(whatever="punk") # <- class > > why would you need that? for example: > > email = String.customize(regex=r'[0-9a-z.]+@[0-9a-z.]+') # (regex > kwarg not supported yet.) > > as I said above, with primitives, there's a shortcut: > > email = String(regex='[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not > supported yet.) > > This statement implicitly calls customize, and produces a new String > type on the fly. > Is this not possible to achieve for custom types? I'd rather that things were consistent and certainly the primitive shortcut is more natural. > > (maybe the word customize is too long?) > > 2) @soapmethod is renamed to @rpc > Fine :) But this release will certainly have to be 0.9 or 1.0 as its going to break compatibility for current users (nothing major to change for them though). > > 3) xml and etimport modules are gone, nsmap is now just a python dict. > get_datatype and friends are gone. you can use get_type_name and > get_type_name_ns methods. soaplib.get_namespace_prefix(namespace) > manages the namespaces and prefixes automatically. > > from lxml import etree > > parent = etree.Element("{%s}parent % namespace) > child = etree.SubElement(parent, "{%s}child" % namespace) > > is what we do now. > OK, great, this was essentially someone just reviewing the changes I made to introduce namespace support anyway so its good that this has finally happened! > > 5) CamelCase is only used for class names. anything else has > underscores_separating_words. > We should be using PEP8 style and preferably enforcing this in setup.py by bundling and running the pep8.py script. > > 7) thanks to better modularization of serializers.primitive module, a > nice chunk of duplicate code was removed. > Always a win. > > 8) hooks api was updated. as said above, camelCase is gone. > additionally, on_results takes an additional argument to let you modify > http headers. > Fine. > > 9) python's logging module is now used. debug statements should be > ignored when not debugging. > Great - I despise using code that is littered with print() statements :) > > fwiw, these are mostly to scratch my own itches. > > awaiting your feedback. please help with documentation! > Good work anyway Burak. I noticed also that in your fork you had removed the client code. I suggested this a while back as I felt that SUDS had it covered and I didn't want to duplicate efforts with them but I seem to recall some people shouting that they used this code. What is your feeling on the matter? > > best, > burak > > > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkp at kirkconsulting.co.uk Mon Jun 21 20:03:33 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Mon, 21 Jun 2010 19:03:33 +0100 Subject: [Soap-Python] Changelog since 0.8.1 In-Reply-To: References: Message-ID: Hi Jonathan Sorry for the delay. In answer to your question, no there isn't a changelog (there should be so applogies) but since 0.8.x is the series post-lxml I can just say that nothing major has changed (yet) - just a bunch of small fixes from various users in the wild. Burak has a bunch of bigger changes in the pipeline that will mean some changes for existing users but they aren't in yet. -- Jamie Kirkpatrick 07818 422311 On 10 June 2010 10:51, Jonathan Endersby wrote: > Hi > > I haven't switched to the dev version simply because I'm too > scared.... Is there a changelog somewhere with the biggest bits to > look at? > > j. > > -- > Jonathan Endersby > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Mon Jun 21 21:16:23 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Mon, 21 Jun 2010 22:16:23 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib In-Reply-To: References: <4C1E8C7E.2040002@arskom.com.tr> Message-ID: <4C1FBA87.2060308@arskom.com.tr> On 06/21/10 20:50, Jamie Kirkpatrick wrote: > Hi Burak > > Thanks very much for the updates. I have some thoughts reading back > what you've said but they aren't very fully formed :) > > 1) the class/instance inconsistency is gone. > > > > > Great, definitely makes sense. > > > > c=NotSoComplexType.customize(whatever="punk") # <- class > > why would you need that? for example: > > email = String.customize(regex=r'[0-9a-z.]+@[0-9a-z.]+') # (regex > kwarg not supported yet.) > > as I said above, with primitives, there's a shortcut: > > email = String(regex='[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not > supported yet.) > > This statement implicitly calls customize, and produces a new String > type on the fly. > > > Is this not possible to achieve for custom types? I'd rather that > things were consistent and certainly the primitive shortcut is more > natural. I think *instantiating* the custom types is more natural. Such a distinction exists between Python primitives (immutable types, as guido calls them) and custom types as well, so I thought it wouldn't be big deal. class Punk(ClassSerializer): foo = String bar = Integer punk = Punk() # <- instance see: http://www.python.org/download/releases/2.2/descrintro/ > > 2) @soapmethod is renamed to @rpc > > > Fine :) But this release will certainly have to be 0.9 or 1.0 as its > going to break compatibility for current users (nothing major to > change for them though). sure. once i'm done with this, my aim is to integrate other rpc protocols without changing the api, that's why i'm getting rid of the soap word everywhere. > > Good work anyway Burak. Thanks! > I noticed also that in your fork you had removed the client code. I > suggested this a while back as I felt that SUDS had it covered and I > didn't want to duplicate efforts with them but I seem to recall some > people shouting that they used this code. What is your feeling on the > matter? > here's my opinion on this subject: http://groups.google.com/group/soapliboptio/msg/bd1de7b5e7833edf I don't know about others, but I'm not willing to spend resources on a second soap client, when there's a perfectly fine alternative. For those people who absolutely need soaplib's soap client, I think it's time to switch to a proper soap client, or fork jkp/soaplib repository and take it from there. Best regards, Burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradallen137 at gmail.com Tue Jun 22 05:57:08 2010 From: bradallen137 at gmail.com (Brad Allen) Date: Mon, 21 Jun 2010 22:57:08 -0500 Subject: [Soap-Python] Twisted SOAP server Message-ID: I just learned that Twisted has some built-in SOAP support...based on some of the module names I'm guess it uses SOAPpy. http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html Has anybody here tried using soaplib with Twisted? From burak.arslan at arskom.com.tr Tue Jun 22 19:16:33 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Tue, 22 Jun 2010 20:16:33 +0300 Subject: [Soap-Python] whoops Message-ID: <4C20EFF1.4010807@arskom.com.tr> hi, fyi, i mistakenly merged my repo with jkp, trying to merge snaptv with jkp. i did revert the merge, but the history is there. there doesn't seem to be an easy way to pretend as if it never happened. see: http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt from what i gather, it'll just be a bit time consuming to merge my changes back. apart from that, everything should be ok. best regards, burak From burak.arslan at arskom.com.tr Wed Jun 23 16:07:20 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 23 Jun 2010 17:07:20 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib In-Reply-To: <4C1E8C7E.2040002@arskom.com.tr> References: <4C1E8C7E.2040002@arskom.com.tr> Message-ID: <4C221518.2050500@arskom.com.tr> hi, i've just pushed another bunch of fixes and updates. one notable change is about thread local storage. as you may know, twisted is a framework that enables us to juggle multiple tasks inside one process. this was not compatible with thread-local global request object in wsgi_soap.py so it's now gone. you can modify soap_headers inside hooks, except when there's an exception. there's a FIXME for that. also, a soap request/response cycle seems to be working as of now. no guarantees yet, though. best, burak On 06/21/10 00:47, Burak Arslan wrote: > hi, > > i've recently committed a large diff to my own repo. the most important > point is that nothing is working yet. some less important points, in no > particular order, follow: > > 1) the class/instance inconsistency is gone. Before: > > class NotSoComplexType(ClassSerializer): > class types: > a=Integer > > class ComplexType(ClassSerializer): > class types: > a=Array(String) # <- instance > b=String # <- class > c=NotSoComplexType # <- class > > after: > > class ComplexType(ClassSerializer): > a=Array(String) # <- class > b=String # <- class > c=NotSoComplexType # <- class > > > Primitive classes' __new__ is overridden to return a *copy* of the > original class definition instead of an *instance* of the original class > definition. > > However: > > class ComplexType(ClassSerializer): > a=Array(String) # <- class > b=String # <- class > c=NotSoComplexType() # <- instance. don't do this! > > Instead: > > class ComplexType(ClassSerializer): > a=Array(String) # <- class > b=String # <- class > c=NotSoComplexType.customize(whatever="punk") # <- class > > why would you need that? for example: > > email = String.customize(regex=r'[0-9a-z.]+@[0-9a-z.]+') # (regex > kwarg not supported yet.) > > as I said above, with primitives, there's a shortcut: > > email = String(regex='[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not > supported yet.) > > This statement implicitly calls customize, and produces a new String > type on the fly. > > (maybe the word customize is too long?) > > 2) @soapmethod is renamed to @rpc > > 3) xml and etimport modules are gone, nsmap is now just a python dict. > get_datatype and friends are gone. you can use get_type_name and > get_type_name_ns methods. soaplib.get_namespace_prefix(namespace) > manages the namespaces and prefixes automatically. > > from lxml import etree > > parent = etree.Element("{%s}parent % namespace) > child = etree.SubElement(parent, "{%s}child" % namespace) > > is what we do now. > > 5) CamelCase is only used for class names. anything else has > underscores_separating_words. > > 6) Multiple namespaces are (will be) supported. > > Before: > > import m1 > import m2 > > class ComplexObject(ClassSerializer): > class types: > a=m1.Punk > b=m2.Punk > > m1.Punk was overwritten by m2.Punk (or vice versa). > > After: > > Separate tags are inserted for each python namespace. Currently > it is not working because there are no tags inside > tags. first thing to do once I get some time. > > 7) thanks to better modularization of serializers.primitive module, a > nice chunk of duplicate code was removed. > > 8) hooks api was updated. as said above, camelCase is gone. > additionally, on_results takes an additional argument to let you modify > http headers. > > 9) python's logging module is now used. debug statements should be > ignored when not debugging. > > fwiw, these are mostly to scratch my own itches. > > awaiting your feedback. please help with documentation! > > best, > burak > > > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > From amorales at ull.es Wed Jun 23 17:21:10 2010 From: amorales at ull.es (Alberto Morales) Date: Wed, 23 Jun 2010 16:21:10 +0100 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: References: Message-ID: <4C222666.6080909@ull.es> Brad Allen escribi?: > I just learned that Twisted has some built-in SOAP support...based on > some of the module names I'm guess it uses SOAPpy. > > http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html > > Has anybody here tried using soaplib with Twisted? > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > Hello, A few months ago, i tried a proof of concept of running soaplib inside a twisted reactor. I attach the recipe. It is done using versions in Debian Lenny. It should be accesible v?a http://localhost:8080/hello/?service.wsdl Greetings. ==== from soaplib.wsgi_soap import SimpleWSGISoapApp from soaplib.service import soapmethod from soaplib.serializers.primitive import Array, String class HelloWorldService(SimpleWSGISoapApp): @soapmethod(_returns=Array(String)) def hello(self): "A method that says hello" return ["hello", "world"] if __name__=='__main__': from twisted.web import server, wsgi, resource from twisted.internet import reactor server_name='0.0.0.0' server_port=8080 root = resource.Resource() root.putChild("hello", wsgi.WSGIResource(reactor, reactor.getThreadPool(), HelloWorldService())) reactor.listenTCP(server_port, server.Site(root), interface=server_name) reactor.run() -- Alberto Morales Diaz Tecnico Especialista de Gestion - Area de Servicios TIC Telefono/Phone: +34 922 845087 Fax: +34 922 319259 Correo/Email: amorales at ull.es www.ccti.ull.es Centro de Comunicaciones y Tecnologias de la Informacion (CCTI) Universidad de La Laguna (ULL) From amorales at ull.es Wed Jun 23 17:38:33 2010 From: amorales at ull.es (Alberto Morales) Date: Wed, 23 Jun 2010 16:38:33 +0100 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: References: <4C222666.6080909@ull.es> Message-ID: <4C222A79.6010205@ull.es> Jason Baker escribi?: > On Wed, Jun 23, 2010 at 10:21 AM, Alberto Morales > wrote: > > Brad Allen escribi?: > > I just learned that Twisted has some built-in SOAP > support...based on > some of the module names I'm guess it uses SOAPpy. > > http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html > > Has anybody here tried using soaplib with Twisted? > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > > > Hello, > > A few months ago, i tried a proof of concept of running soaplib > inside a twisted reactor. I attach the recipe. It is done using > versions in Debian Lenny. It should be accesible v?a > http://localhost:8080/hello/?service.wsdl > > Greetings. > > ==== > > from soaplib.wsgi_soap import SimpleWSGISoapApp > from soaplib.service import soapmethod > from soaplib.serializers.primitive import Array, String > > class HelloWorldService(SimpleWSGISoapApp): > @soapmethod(_returns=Array(String)) > def hello(self): > "A method that says hello" > return ["hello", "world"] > > if __name__=='__main__': > from twisted.web import server, wsgi, resource > from twisted.internet import reactor > server_name='0.0.0.0' > server_port=8080 > root = resource.Resource() > root.putChild("hello", wsgi.WSGIResource(reactor, > reactor.getThreadPool(), HelloWorldService())) > reactor.listenTCP(server_port, server.Site(root), > interface=server_name) > reactor.run() > > > Correct me if I'm wrong, but doesn't using WSGI like this defeat the > purpose of using Twisted? After all, WSGI is inherently synchronous. Of course. The rest of my app is done using Callbacks and Deferrers, and this is the only code that runs synchronous and i couldn't made it work in other way. Soap support in my app is not very used, so it was enough for me this way. -- Alberto Morales Diaz Tecnico Especialista de Gestion - Area de Servicios TIC Telefono/Phone: +34 922 845087 Fax: +34 922 319259 Correo/Email: amorales at ull.es www.ccti.ull.es Centro de Comunicaciones y Tecnologias de la Informacion (CCTI) Universidad de La Laguna (ULL) From jbaker at zeomega.com Wed Jun 23 17:25:23 2010 From: jbaker at zeomega.com (Jason Baker) Date: Wed, 23 Jun 2010 10:25:23 -0500 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: <4C222666.6080909@ull.es> References: <4C222666.6080909@ull.es> Message-ID: On Wed, Jun 23, 2010 at 10:21 AM, Alberto Morales wrote: > Brad Allen escribi?: > >> I just learned that Twisted has some built-in SOAP support...based on >> some of the module names I'm guess it uses SOAPpy. >> >> http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html >> >> Has anybody here tried using soaplib with Twisted? >> _______________________________________________ >> Soap mailing list >> Soap at python.org >> http://mail.python.org/mailman/listinfo/soap >> >> > Hello, > > A few months ago, i tried a proof of concept of running soaplib inside a > twisted reactor. I attach the recipe. It is done using versions in Debian > Lenny. It should be accesible v?a > http://localhost:8080/hello/?service.wsdl > > Greetings. > > ==== > > from soaplib.wsgi_soap import SimpleWSGISoapApp > from soaplib.service import soapmethod > from soaplib.serializers.primitive import Array, String > > class HelloWorldService(SimpleWSGISoapApp): > @soapmethod(_returns=Array(String)) > def hello(self): > "A method that says hello" > return ["hello", "world"] > > if __name__=='__main__': > from twisted.web import server, wsgi, resource > from twisted.internet import reactor > server_name='0.0.0.0' > server_port=8080 > root = resource.Resource() > root.putChild("hello", wsgi.WSGIResource(reactor, > reactor.getThreadPool(), HelloWorldService())) > reactor.listenTCP(server_port, server.Site(root), interface=server_name) > reactor.run() > Correct me if I'm wrong, but doesn't using WSGI like this defeat the purpose of using Twisted? After all, WSGI is inherently synchronous. -------------- next part -------------- An HTML attachment was scrubbed... URL: From optilude at gmail.com Mon Jun 21 18:52:32 2010 From: optilude at gmail.com (Martin Aspeli) Date: Tue, 22 Jun 2010 00:52:32 +0800 Subject: [Soap-Python] Fault details Message-ID: Hi, I'm using Soaplib to implement a mock of a Java-based service that we'll eventually connect to, for testing purposes. I've managed to generate the requisite soaplib stubs from the published WSDL of that service (see http://stackoverflow.com/questions/3083186/generating-python-soaplib-stubs-from-wsdl for filthy code to that purpose). However, I've noticed one thing we can't seem to mock: Any fault raised by the application is supposed to have a 'details' attribute that's a lost of complex objects (in this case, of type SOAPException, which is a complex type specified by the WSDL). I tried something like this: faultDetail = SOAPException() faultDetail.message = u"The message" raise Fault(faultstring=u"Error 123", detail=[faultDetail]) However, this crashes when soaplib tries to serialise the message. It seems it expects details to always be a string. Suds (which we happen to use as a client) seems to expect it to be either a string or a list of objects, like this. Is this a missing feature in soaplib, or something I'm doing wrong? Cheers, Martin From bradallen137 at gmail.com Wed Jun 23 18:42:06 2010 From: bradallen137 at gmail.com (Brad Allen) Date: Wed, 23 Jun 2010 11:42:06 -0500 Subject: [Soap-Python] recent pushes to plq/soaplib In-Reply-To: <4C221518.2050500@arskom.com.tr> References: <4C1E8C7E.2040002@arskom.com.tr> <4C221518.2050500@arskom.com.tr> Message-ID: Burak, that is interesting. Are you planning to use soaplib with Twisted, or are you just trying to leave open the possiblity for others to do so? On Wed, Jun 23, 2010 at 9:07 AM, Burak Arslan wrote: > hi, > > i've just pushed another bunch of fixes and updates. > > one notable change is about thread local storage. > > as you may know, twisted is a framework that enables us to juggle > multiple tasks inside one process. this was not compatible with > thread-local global request object in wsgi_soap.py so it's now gone. you > can modify soap_headers inside hooks, except when there's an exception. > there's a FIXME for that. > > also, a soap request/response cycle seems to be working as of now. no > guarantees yet, though. > > best, > burak > > > On 06/21/10 00:47, Burak Arslan wrote: >> hi, >> >> i've recently committed a large diff to my own repo. the most important >> point is that nothing is working yet. some less important points, in no >> particular order, follow: >> >> 1) the class/instance inconsistency is gone. Before: >> >> class NotSoComplexType(ClassSerializer): >> ? ?class types: >> ? ? ? a=Integer >> >> class ComplexType(ClassSerializer): >> ? ?class types: >> ? ? ? a=Array(String) ? ?# <- instance >> ? ? ? b=String ? ? ? ? ? # <- class >> ? ? ? c=NotSoComplexType # <- class >> >> after: >> >> class ComplexType(ClassSerializer): >> ? ?a=Array(String) ? ?# <- class >> ? ?b=String ? ? ? ? ? # <- class >> ? ?c=NotSoComplexType # <- class >> >> >> Primitive classes' __new__ is overridden to return a *copy* of the >> original class definition instead of an *instance* of the original class >> definition. >> >> However: >> >> class ComplexType(ClassSerializer): >> ? ?a=Array(String) ? ? ?# <- class >> ? ?b=String ? ? ? ? ? ? # <- class >> ? ?c=NotSoComplexType() # <- instance. don't do this! >> >> Instead: >> >> class ComplexType(ClassSerializer): >> ? ?a=Array(String) ? ? ?# <- class >> ? ?b=String ? ? ? ? ? ? # <- class >> ? ?c=NotSoComplexType.customize(whatever="punk") # <- class >> >> why would you need that? for example: >> >> ? ?email = String.customize(regex=r'[0-9a-z.]+@[0-9a-z.]+') # (regex >> kwarg not supported yet.) >> >> as I said above, with primitives, there's a shortcut: >> >> ? ?email = String(regex='[0-9a-z.]+@[0-9a-z.]+') # (regex kwarg not >> supported yet.) >> >> This statement implicitly calls customize, and produces a new String >> type on the fly. >> >> (maybe the word customize is too long?) >> >> 2) @soapmethod is renamed to @rpc >> >> 3) xml and etimport modules are gone, nsmap is now just a python dict. >> get_datatype and friends are gone. you can use get_type_name and >> get_type_name_ns methods. soaplib.get_namespace_prefix(namespace) >> manages the namespaces and prefixes automatically. >> >> from lxml import etree >> >> parent = etree.Element("{%s}parent % namespace) >> child = etree.SubElement(parent, "{%s}child" % namespace) >> >> is what we do now. >> >> 5) CamelCase is only used for class names. anything else has >> underscores_separating_words. >> >> 6) Multiple namespaces are (will be) supported. >> >> Before: >> >> import m1 >> import m2 >> >> class ComplexObject(ClassSerializer): >> ? ? class types: >> ? ? ? ? a=m1.Punk >> ? ? ? ? b=m2.Punk >> >> m1.Punk was overwritten by m2.Punk (or vice versa). >> >> After: >> >> Separate tags are inserted for each python namespace. Currently >> it is not working because there are no tags inside >> tags. first thing to do once I get some time. >> >> 7) thanks to better modularization of serializers.primitive module, a >> nice chunk of duplicate code was removed. >> >> 8) hooks api was updated. as said above, camelCase is gone. >> additionally, on_results takes an additional argument to let you modify >> http headers. >> >> 9) python's logging module is now used. debug statements should be >> ignored when not debugging. >> >> fwiw, these are mostly to scratch my own itches. >> >> awaiting your feedback. please help with documentation! >> >> 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 burak.arslan at arskom.com.tr Wed Jun 23 20:14:53 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 23 Jun 2010 21:14:53 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib In-Reply-To: References: <4C1E8C7E.2040002@arskom.com.tr> <4C221518.2050500@arskom.com.tr> Message-ID: <1277316893.12756.5.camel@Nokia-N900> ----- Original message ----- > Burak, that is interesting. Are you planning to use soaplib with > Twisted, or are you just trying to leave open the possiblity for > others to do so? > well, people are already doing it and it was not a good programming practice anyway. burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkp at kirkconsulting.co.uk Fri Jun 25 10:00:15 2010 From: jkp at kirkconsulting.co.uk (Jamie Kirkpatrick) Date: Fri, 25 Jun 2010 09:00:15 +0100 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: References: <4C222666.6080909@ull.es> Message-ID: Correct, it does somewhat defeat the point. Async WSGI has long been discussed but a standard was never arrived at (though a PEP was proposed). I once wrote some experimental code using Greenlets to emulate this kind of functionality however (running under Tornado but the same idea): http://gist.github.com/240571. -- Jamie Kirkpatrick 07818 422311 On 23 June 2010 16:25, Jason Baker wrote: > On Wed, Jun 23, 2010 at 10:21 AM, Alberto Morales wrote: > >> Brad Allen escribi?: >> >>> I just learned that Twisted has some built-in SOAP support...based on >>> some of the module names I'm guess it uses SOAPpy. >>> >>> http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html >>> >>> Has anybody here tried using soaplib with Twisted? >>> _______________________________________________ >>> Soap mailing list >>> Soap at python.org >>> http://mail.python.org/mailman/listinfo/soap >>> >>> >> Hello, >> >> A few months ago, i tried a proof of concept of running soaplib inside a >> twisted reactor. I attach the recipe. It is done using versions in Debian >> Lenny. It should be accesible v?a >> http://localhost:8080/hello/?service.wsdl >> >> Greetings. >> >> ==== >> >> from soaplib.wsgi_soap import SimpleWSGISoapApp >> from soaplib.service import soapmethod >> from soaplib.serializers.primitive import Array, String >> >> class HelloWorldService(SimpleWSGISoapApp): >> @soapmethod(_returns=Array(String)) >> def hello(self): >> "A method that says hello" >> return ["hello", "world"] >> >> if __name__=='__main__': >> from twisted.web import server, wsgi, resource >> from twisted.internet import reactor >> server_name='0.0.0.0' >> server_port=8080 >> root = resource.Resource() >> root.putChild("hello", wsgi.WSGIResource(reactor, >> reactor.getThreadPool(), HelloWorldService())) >> reactor.listenTCP(server_port, server.Site(root), interface=server_name) >> reactor.run() >> > > Correct me if I'm wrong, but doesn't using WSGI like this defeat the > purpose of using Twisted? After all, WSGI is inherently synchronous. > > _______________________________________________ > Soap mailing list > Soap at python.org > http://mail.python.org/mailman/listinfo/soap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Fri Jun 25 10:30:33 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Fri, 25 Jun 2010 11:30:33 +0300 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: References: <4C222666.6080909@ull.es> Message-ID: <4C246929.9010207@arskom.com.tr> On 06/25/10 11:00, Jamie Kirkpatrick wrote: > I once wrote some experimental code using Greenlets to emulate this > kind of functionality however (running under Tornado but the same > idea): http://gist.github.com/240571. > hi, why one would use async frameworks with soaplib? for performance reasons? is there a notable difference? as of now, soaplib itself is a cpu-intensive piece of code dealing with data that's already in memory (except, maybe, the binary serializer). so there are no gaps to be filled by cooperative multitasking, hence no callback interface to soaplib. but then, this makes it impossible to process data while part of it is available, or process huge soap requests with only parts of it in memory. (by the way, there are no message limits in soaplib as far as i know, so soaplib is currently open to denial-of-service attacks) best regards, burak From robinp at snap.tv Fri Jun 25 10:26:55 2010 From: robinp at snap.tv (Robin Pedersen) Date: Fri, 25 Jun 2010 10:26:55 +0200 Subject: [Soap-Python] Twisted SOAP server In-Reply-To: References: <4C222666.6080909@ull.es> Message-ID: On Fri, 25 Jun 2010 10:00:15 +0200, Jamie Kirkpatrick wrote: > Correct, it does somewhat defeat the point. Async WSGI has long been > discussed but a standard was never arrived at (though a PEP was > proposed). > > I once wrote some experimental code using Greenlets to emulate this kind > of > functionality however (running under Tornado but the same idea): > http://gist.github.com/240571. > However, - twisted does support WSGI - soaplib uses WSGI (at least all the examples do) When you have an application that is already based on twisted, it makes sense to use twisted WSGI, instead of an alternative. That said, it would be great to have "real" twisted support. -- Best regards, Robin Pedersen From burak.arslan at arskom.com.tr Tue Jun 29 00:13:37 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Tue, 29 Jun 2010 01:13:37 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib - all tests are green Message-ID: <4C291E91.7090103@arskom.com.tr> hi, fyi, with recent pushes my repo, all tests are green again. please start playing with it, and write tests for bugs that you stumble upon. best, burak From burak.arslan at arskom.com.tr Tue Jun 29 18:11:10 2010 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Tue, 29 Jun 2010 19:11:10 +0300 Subject: [Soap-Python] recent pushes to plq/soaplib - all tests are green In-Reply-To: <4C291E91.7090103@arskom.com.tr> References: <4C291E91.7090103@arskom.com.tr> Message-ID: <4C2A1B1E.4070002@arskom.com.tr> On 06/29/10 01:13, Burak Arslan wrote: > hi, > > fyi, with recent pushes my repo, all tests are green again. > > please start playing with it, and write tests for bugs that you stumble > upon. > > best, > burak > > hi again, today's commits include experimental inheritance and enumeration support. lots of fixes about namespace resolution and preliminary suds interop tests also went in in today's batch. best regards, burak