qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gibson, Jack" <jagib...@paypal.com.INVALID>
Subject Re: Proton tutorial: synchronous request-response
Date Tue, 30 Sep 2014 16:05:46 GMT
Its great to see some more real world use cases being created but how
about some proton-j examples? It seems to be woefully behind to the point
where even some of the out of the box examples aren¹t fully functionally
anymoreŠ

Jack




On 9/22/14, 12:51 PM, "Alan Conway" <aconway@redhat.com> wrote:

>On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
>> 
>>http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
>>client.py?view=markup&pathrev=1626029
>> 
>> I think "invoke" is an unintuitive name there.  It's not "invoking the
>> request" or "invoking the client".  Invoke usually implies a named
>>piece of
>> application logic.  I think in this case "send" or "send_request" would
>>be
>> better, as in "send the request (and this is a request for which I
>>expect a
>> synchronous response)".
>
>Yes I don't really like invoke either but I also don't like send. I want
>to say: "send a request *and* wait for a response". The word "send" is
>heavily used already in all the messaging APIs to mean "just send a
>message".
>
>I also considered "call". This really is the moral equivalent of an RPC
>(C for "call") The only difference between this and RPC is dressing it
>up as a method call on a proxy object instead of exposing the underlying
>message exchange. However given that we want to expose this as a message
>exchange, neither "invoke" nor "call" is very satisfying.
>
>I'd love a better alternative!
>
>> 
>> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <aconway@redhat.com> wrote:
>> 
>> > I checked this in on the examples branch.
>> >
>> > 
>>------------------------------------------------------------------------
>> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
>> > lines
>> >
>> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
>> > request-response client.
>> >
>> > This client uses the familiar paradigm of making blocking calls that
>> > send a
>> > request and return the response.
>> >
>> > Made some improvements to BlockingThread error handling and timeouts.
>> >
>> > 
>>------------------------------------------------------------------------
>> >
>> > It needs a little work to be realistic (needs to check correlation ids
>> > at least) but it is quite neat.
>> >
>> > Most of the current tutorial examples are in an event driven style,
>> > which is great for servers and intermediaries but less familiar on the
>> > client side. This demo shows that you can also do traditional
>> > client-driven request response quite easily. The error handling is
>> > simple: invoke() throws if anything goes wrong.
>> >
>> > I did this the hard way first - by writing my own raw event handlers.
>>It
>> > was instructive but, well, hard. Then I noticed Gordon's
>> > BlockingConnection class already did everything I had figured out the
>> > hard way (blocking and error handing) so I rewrote it using that and
>>it
>> > was very easy.
>> >
>> > So far I think this is promising.
>> >
>> > Cheers,
>> > Alan.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>> >
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message