Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of
 prvs=73518f9c31=rhs@alum.mit.edu designates 18.7.68.20 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D0517223.253B9%jamesmartin@paypal.com>
References: <1411061014.2381.10.camel@localhost>
	<CANVjZ_R6DWSM-pgi0TiMaVJCfqHAbh7RSnVDJg4fcYMjPGfVhg@mail.gmail.com>
	<1411408261.3082.45.camel@localhost>
	<D0503EBE.34C62%jagibson@ebay.com>
	<CACL1BnBQ3snijsLNLFReieCGQ9kA8VDEh4-18utTWk7shfLqfg@mail.gmail.com>
	<D0517223.253B9%jamesmartin@paypal.com>
Date: Wed, 1 Oct 2014 10:55:04 -0400
Message-ID: 
 <CACL1BnC6-d44Nbz0KHQ32CgRCzHwDXkG=S9SkkSm6T_Ma9G-Gg@mail.gmail.com>
Subject: Re: Proton tutorial: synchronous request-response
From: Rafael Schloming <rhs@alum.mit.edu>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=f46d044401ce6ab02305045daf4e

--f46d044401ce6ab02305045daf4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 officia=
l
> 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 th=
e
> >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=C2=B9t fully funct=
ionally
> >> anymore=C5=A0
> >>
> >> 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=3Dmarkup&pathrev=3D1626029
> >> >>
> >> >> 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" i=
s
> >> >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 R=
PC
> >> >(C for "call") The only difference between this and RPC is dressing i=
t
> >> >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 synchrono=
us
> >> >> > 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 correlatio=
n
> >>ids
> >> >> > at least) but it is quite neat.
> >> >> >
> >> >> > Most of the current tutorial examples are in an event driven styl=
e,
> >> >> > which is great for servers and intermediaries but less familiar o=
n
> >>the
> >> >> > client side. This demo shows that you can also do traditional
> >> >> > client-driven request response quite easily. The error handling i=
s
> >> >> > 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
>
>

--f46d044401ce6ab02305045daf4e--