qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin, Jimmy" <jamesmar...@paypal.com.INVALID>
Subject Re: Proton tutorial: synchronous request-response
Date Wed, 01 Oct 2014 17:28:16 GMT
That’s good to know. Do you have a tentative timeline for this work?

On 10/1/14, 9:55 AM, "Rafael Schloming" <rhs@alum.mit.edu> wrote:

>Yes, right now the demo consists of some shared convenience/utility code
>along side the Spout, Drain, and Server classes that define the actual
>client/server behavior. I intend to pull the utility code into proton-j
>proper and pull in the Spout, Drain, and Server classes (or possibly a
>simplified/better documented version of them) as examples.
>
>--Rafael
>
>On Wed, Oct 1, 2014 at 9:58 AM, Martin, Jimmy <
>jamesmartin@paypal.com.invalid> wrote:
>
>> Rafael,
>>
>> Do you envision the code in your demo async framework becoming an
>>official
>> part of proton-j in the future? I thought you had said something to that
>> effect in a previous post.
>>
>> -Jimmy
>>
>> On 10/1/14, 6:54 AM, "Rafael Schloming" <rhs@alum.mit.edu> wrote:
>>
>> >I have a set of examples for proton-j that is more current. They were
>> >developed midway through the 0.8 development cycle so they may need a
>> >little bit of updating, but I intend to verify that they work against
>>the
>> >release, add a bit of docs and include them in 0.8 RC2.
>> >
>> >You can check them out here for now:
>> >
>> >  https://github.com/rhs/qpid-proton-demo
>> >
>> >--Rafael
>> >
>> >
>> >On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack
>> ><jagibson@paypal.com.invalid>
>> >wrote:
>> >
>> >> 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
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> 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