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 aconway@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <1411408261.3082.45.camel@localhost>
Subject: Re: Proton tutorial: synchronous request-response
From: Alan Conway <aconway@redhat.com>
To: users@qpid.apache.org
Date: Mon, 22 Sep 2014 13:51:01 -0400
In-Reply-To: 
 <CANVjZ_R6DWSM-pgi0TiMaVJCfqHAbh7RSnVDJg4fcYMjPGfVhg@mail.gmail.com>
References: <1411061014.2381.10.camel@localhost>
	 <CANVjZ_R6DWSM-pgi0TiMaVJCfqHAbh7RSnVDJg4fcYMjPGfVhg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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