Hi,

Patches updated in ticket 312.

I will be more than happy to hear for your (or anyone else's experience) with the usage of this patch.

Best regards

Daniel

On Mon, May 3, 2010 at 19:48, jathan. <jathan@gmail.com> wrote:
THANK YOU for providing this!   I was definitely one of the people (if
not THE person) asking if this kind of thing were possible because of
my need to use Suds with Twisted.

I am going to test this out and report back.

On Mon, May 3, 2010 at 3:32 AM, Daniel Rodriguez <danjrod@gmail.com> wrote:
> Hello again,
> I decided that a couple of additional modifications to avoid code
> duplication wouldn't hurt and it looks better than I expected.
> Since the trac system is not letting me log in right now and in case anyone
> would be interested in testing the asynchronous usage, this two patches have
> to be applied to suds/client.py and suds/options.py
> As soon as the trac system allow it, the patches will be uploaded to the
> server
>
>
> On Mon, May 3, 2010 at 01:29, Daniel Rodriguez <danjrod@gmail.com> wrote:
>>
>> Dear Jeff et al,
>> Some weeks ago someone mentioned the possibility of using the library
>> asynchronously, what would enable its usage with other libraries like
>> Twisted and maybe avoid multithreaded scenarios.
>> I have implemented a small set of changes that allow the library to be
>> used asynchronously (ticket 312)
>> Changes:
>> -- suds/options.py
>>
>> Addition of option: "async" with a default value of False. This enables
>> the library to behave as it does today
>>
>> -- suds/client.py
>>
>> Client.send (changed)
>>
>> If async is True, a suds.transport.Request will be returned. This delivers
>> all needed information (url, headers, message) to talk to the server
>>
>> Client.processreply(new)
>>
>> Processes a reply offline. Called by Method.processreply. The behaviour
>> tries to mimic the original behavious and thus it will raise exceptions if
>> needed be
>>
>> Part of the code in Client.send and in this method could be put in two
>> separate methods to avoid code duplication, but I think that for an initial
>> implementation, it is better to make as few changes as possible to the
>> original code.
>>
>> Method.processreply(new)
>>
>> Takes a suds.transport.Reply (which has code, headers and data) to invoke
>> Client.processreply
>>
>> It has worked in my tests and I guess the changes are so few that it will
>> probably work.
>> A usage example:
>>
>> client = suds.client(wsdl, async = True)
>> httprequest = client.service.mymethod(args) (the returned type is
>> suds.transport.Request)
>> httpreply = communicate_with_server(httprequest.url, httprequest.headers,
>> httprequest.message)
>> reply = suds.transport.Reply(httpreply.code, httpreply.headers,
>> http.message)
>> response = suds.client.service.mymethod.processreply(reply)
>>
>> Best regards
>> Daniel
>>
>
>
> _______________________________________________
> suds mailing list
> suds@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
>



--
Jathan.
-