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" <acon...@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 <acon...@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-unsubscr...@qpid.apache.org >> > For additional commands, e-mail: users-h...@qpid.apache.org >> > >> > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
