Hello again,
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 regardsDanielOn 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.
-