Fair enough, gzip support is a nice addition :-)
Your async patches look interesting. I started using httplib2 for its
keep-alive and compression support but have been looking for something
that can do pipelining too - your async patches should help solve that
problem (not sure whether urllib3 does, but I'll look into that too).
On Wed, May 5, 2010 at 1:53 PM, Daniel Rodriguez <danjrod(a)gmail.com> wrote:
Hi,
Well, I initially wanted to add the gzip support for the standard transport
created by Jeff. The reason being that it is pretty well integrated with the
overall architecture and most people (including myself) wouldn't probably
care about using any other transport for quick hacks and short scripts.
In theory with the asynchronous usage patch I have provided, using the
library with any other transport should be trivial, given that now suds may
act as a request generator and response processor, with no intervening
network support.
I have started playing with urllib3 (mentioned on the list) to create a
transport based around that library and that has uncovered a bug and in my
opinion a possible need to do some rework of the http and network error
handling.
urlllib3 has also needed some extra work to add proxy support and I am still
doing some work on the error/exception handling and preliminary support for
authentication (server/proxy and basic/digest)
What I was thinking is to ask Jeff to open a contrib directory in the
sources, so that if people contribute things like my urllib3 transport, any
user of the library may choose to import it and use it (but Jeff is probably
busy with many other things as we all are)
Anyhow, thank you becaue I will have a look at Httplib2
Best regards
Daniel
On Wed, May 5, 2010 at 03:27, David Robinson <zxvdr.au(a)gmail.com> wrote:
>
> Hi Daniel,
>
> FWIW, you could use httplib2 for the transport - that would give you
> compression, redirects and keep-alive support for free.
>
> --Dave
>
> On Thu, Apr 29, 2010 at 10:53 PM, Daniel Rodriguez <danjrod(a)gmail.com>
> wrote:
> > Hello,
> > I have added ticket 311 requesting this enhancement with attached
> > patches
> > for transport/http.py and transport/options.py
> > Requesting compression can be turned off and on with the "gzip"
option
> > (a
> > bool)
> > The gzip decompression code works always. The reasoning behind this is:
> >
> > Some network providers may compress the data in HTTP responses in order
> > to
> > decrease network traffic, expecting all clients to be ready to
> > decompress
> > data
> >
> > Best regards
> > Daniel
> > On Sat, Apr 3, 2010 at 21:07, Daniel Rodriguez <danjrod(a)gmail.com>
> > wrote:
> >>
> >> A "break" at the end of the "if" statement will not hurt
and avoid
> >> checking unnecessary headers.
> >> Best regards
> >>
> >> On Sat, Apr 3, 2010 at 02:14, Daniel Rodriguez <danjrod(a)gmail.com>
> >> wrote:
> >>>
> >>> Hi Jeff et al,
> >>> If I am not wrong (I may have missed a configuration option), suds is
> >>> not
> >>> using or requesting gzip compression.
> >>> I have added a few lines and tested at least requesting and accepting
> >>> gzip compression. My changes have been trivial and this could be
> >>> possibly
> >>> added as an option to suds.
> >>> The changes I have made (against 3.9):
> >>> File: suds/transport/http.py:
> >>> Extra imports:
> >>> import gzip
> >>> import StringIO
> >>> Class: HttpTransport
> >>> Method: send
> >>> Added:
> >>> After:
> >>>
> >>> headers = request.headers
> >>>
> >>> added the following line
> >>>
> >>> headers.update([('Accept-Encoding', 'gzip')])
> >>>
> >>> Changed:
> >>>
> >>> result = Reply(200, fp.headers.dict, fp.read())
> >>>
> >>> to
> >>>
> >>> replydata = fp.read()
> >>> for header in fp.headers.dict.keys():
> >>> if header.lower() == 'content-encoding' and
> >>> fp.headers.dict[header]
> >>> == 'gzip':
> >>> replydatacompressedstream = StringIO.StringIO(replydata)
> >>> gzipper = gzip.GzipFile(fileobj=replydatacompressedstream)
> >>> replydata = gzipper.read()
> >>> result = Reply(200, fp.headers.dict, replydata)
> >>>
> >>> Best regards
> >>> Daniel
> >
> >
> > _______________________________________________
> > suds mailing list
> > suds(a)lists.fedoraproject.org
> >
https://admin.fedoraproject.org/mailman/listinfo/suds
> >