Updating versions (was: 0.3 RC1)
On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote: > Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/ > Java binaries here: > https://repository.apache.org/content/repositories/orgapacheqpid-061/ > > Note that there are the following known issues: > - perl binding tarball has been omitted as the release script didn't work > (still installable via cmake) > - intermittent issues with java driver (java messenger tests are > currently skipped) > - java messenger connection leak > > The above issues are fairly isolated, so I put out the RC anyways so they > wouldn't block testing of other areas. We need to make it a part of the release process to bump the release number in the following files: proton-c/CMakeLists.txt proton-c/bindings/perl/Makefile.PL proton-c/bindings/perl/ChangeLog proton-c/bindings/ruby/lib/qpid_proton/version.rb proton-c/bindings/ruby/ChangeLog Though probably the easiest thing is, when we branch, the above files should all have their versions bumped on trunk. Right now we've got 0.2 for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and Perl is 0.2 (same). -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpBh0VotfRg2.pgp Description: PGP signature
Re: Language example apps...
Hi Mary, It is my understanding that the existing C++ examples should work because the proton based C++ API the Qpid proper API with the proton C API under the covers. That said, I'm not sure what testing has been done to make sure this is true. Also it would seem that perhaps there might be two sets of examples (?). i.e. What happens to old style addresses in the new proton enabled C++ API? Do the still just work? Can I mix simple proton addressing with the more complex previous addressing that allowed us to build exchanges and queues? William - Original Message - > > In terms of depth, I'm concerned that deep examples will be > > difficult/impossible to maintain well in 5 different languages (6 > > if > > we do something with C++). > > Above you mentioned the possibility of C++ examples. Is anyone > currently > working on creating C++ examples? > > Thanks, > Mary > > -Original Message- > From: Darryl L. Pierce [mailto:dpie...@redhat.com] > Sent: Friday, November 30, 2012 4:05 PM > To: proton@qpid.apache.org > Subject: Re: Language example apps... > > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: > > On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce > wrote: > > > > > Last week Justin asked me to take a look at the examples for > > > Proton > > > across language bindings. What I found are the following: > > > > > > C Python Ruby Perl > > > Mailbox (Raw API)[ ] [X] [X] [ ] > > > Send/Receive (Messenger classes) [ ] [X] [X] [X] > > > Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] > > > > > > > We also have a PHP binding and it has some examples also. > > Yeah, sorry to forget that. > > > What came out of the discussion was that there's a definite lack of > > > depth with the examples. The Mailbox demo is a nice, specific > > > example of stored messaging. The Send/Receive examples show very > > > simple point-to-point messaging. > > > > > > But what else should be included in examples? The first thing > > > that > > > comes to mind is an example demonstrating subscriptions. > > > > > > Ideas? > > > > > > > A couple of random thoughts off the top of my head... > > > > I think the focus for the dynamic language bindings should really > > be > > messenger based examples. I would say it's really not worth having > > non > > messenger examples for the dynamic languages, particularly as those > > kinds of examples are much more involved and maintaining duplicate > > examples involves some significant maintenance effort. I would > > rather > > see a very well maintained/structured C example for the non > > messenger > > stuff. In fact I'd go so far as to say we shouldn't bother exposing > > the non messenger APIs through the bindings at all, with the > > exception > > of python for testing purposes of course. To be clear I'm not > > opposed > > to exposing them, I just don't think there is any demand at this > > point > > and I think it just creates unnecessary work until there is. > > > > In terms of depth, I'm concerned that deep examples will be > > difficult/impossible to maintain well in 5 different languages (6 > > if > > we do something with C++). What I'd suggest we start with is a > > basic, > > well thought out, but simple messenger based example geared towards > > getting people started, and strive to keep that consistent and up > > to > > date across all the bindings. I'd keep deep scenarios to one > > language > > only (at least at first), choosing whichever seems most appropriate > > for that particular deep scenario. > > If we keep the languages as consist as possible across the bindings, > then > one language doing a deep example and others doing more general > examples > should be workable. Assuming the one language is as easy to > understand for > someone not familiar with it to follow. > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > > > >
Re: Updating versions (was: 0.3 RC1)
On Wed, Jan 2, 2013 at 11:42 AM, Darryl L. Pierce wrote: > On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote: > > Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/ > > Java binaries here: > > https://repository.apache.org/content/repositories/orgapacheqpid-061/ > > > > Note that there are the following known issues: > > - perl binding tarball has been omitted as the release script didn't > work > > (still installable via cmake) > > - intermittent issues with java driver (java messenger tests are > > currently skipped) > > - java messenger connection leak > > > > The above issues are fairly isolated, so I put out the RC anyways so they > > wouldn't block testing of other areas. > > We need to make it a part of the release process to bump the release > number in the following files: > > proton-c/CMakeLists.txt > proton-c/bindings/perl/Makefile.PL > proton-c/bindings/perl/ChangeLog > proton-c/bindings/ruby/lib/qpid_proton/version.rb > proton-c/bindings/ruby/ChangeLog > > Though probably the easiest thing is, when we branch, the above files > should all have their versions bumped on trunk. Right now we've got 0.2 > for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and > Perl is 0.2 (same). > Can we make these all reference the same source? I noticed the proton-c was off and was going to include a fix for that in RC2. It would be nice if the other places picked up the correct version automatically. --Rafael
Re: Language example apps...
Why would examples in every normative language not be appropriate? Synchronization may be an issue, but wouldn't examples be easily synchronized with language-specific API updates? On Wed, Jan 2, 2013 at 12:50 PM, William Henry wrote: > Hi Mary, > > It is my understanding that the existing C++ examples should work because > the proton based C++ API the Qpid proper API with the proton C API under > the covers. > > That said, I'm not sure what testing has been done to make sure this is > true. > > Also it would seem that perhaps there might be two sets of examples (?). > i.e. What happens to old style addresses in the new proton enabled C++ API? > Do the still just work? Can I mix simple proton addressing with the more > complex previous addressing that allowed us to build exchanges and queues? > > William > > - Original Message - > > > In terms of depth, I'm concerned that deep examples will be > > > difficult/impossible to maintain well in 5 different languages (6 > > > if > > > we do something with C++). > > > > Above you mentioned the possibility of C++ examples. Is anyone > > currently > > working on creating C++ examples? > > > > Thanks, > > Mary > > > > -Original Message- > > From: Darryl L. Pierce [mailto:dpie...@redhat.com] > > Sent: Friday, November 30, 2012 4:05 PM > > To: proton@qpid.apache.org > > Subject: Re: Language example apps... > > > > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: > > > On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce > > wrote: > > > > > > > Last week Justin asked me to take a look at the examples for > > > > Proton > > > > across language bindings. What I found are the following: > > > > > > > > C Python Ruby Perl > > > > Mailbox (Raw API)[ ] [X] [X] [ ] > > > > Send/Receive (Messenger classes) [ ] [X] [X] [X] > > > > Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] > > > > > > > > > > We also have a PHP binding and it has some examples also. > > > > Yeah, sorry to forget that. > > > > > What came out of the discussion was that there's a definite lack of > > > > depth with the examples. The Mailbox demo is a nice, specific > > > > example of stored messaging. The Send/Receive examples show very > > > > simple point-to-point messaging. > > > > > > > > But what else should be included in examples? The first thing > > > > that > > > > comes to mind is an example demonstrating subscriptions. > > > > > > > > Ideas? > > > > > > > > > > A couple of random thoughts off the top of my head... > > > > > > I think the focus for the dynamic language bindings should really > > > be > > > messenger based examples. I would say it's really not worth having > > > non > > > messenger examples for the dynamic languages, particularly as those > > > kinds of examples are much more involved and maintaining duplicate > > > examples involves some significant maintenance effort. I would > > > rather > > > see a very well maintained/structured C example for the non > > > messenger > > > stuff. In fact I'd go so far as to say we shouldn't bother exposing > > > the non messenger APIs through the bindings at all, with the > > > exception > > > of python for testing purposes of course. To be clear I'm not > > > opposed > > > to exposing them, I just don't think there is any demand at this > > > point > > > and I think it just creates unnecessary work until there is. > > > > > > In terms of depth, I'm concerned that deep examples will be > > > difficult/impossible to maintain well in 5 different languages (6 > > > if > > > we do something with C++). What I'd suggest we start with is a > > > basic, > > > well thought out, but simple messenger based example geared towards > > > getting people started, and strive to keep that consistent and up > > > to > > > date across all the bindings. I'd keep deep scenarios to one > > > language > > > only (at least at first), choosing whichever seems most appropriate > > > for that particular deep scenario. > > > > If we keep the languages as consist as possible across the bindings, > > then > > one language doing a deep example and others doing more general > > examples > > should be workable. Assuming the one language is as easy to > > understand for > > someone not familiar with it to follow. > > > > -- > > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > > Delivering value year after year. > > Red Hat ranks #1 in value among software vendors. > > http://www.redhat.com/promo/vendor/ > > > > > > > > > -- Joseph B. Ottinger http://enigmastation.com *Memento mori.*
RE: Language example apps...
Thanks Henry, I asked my question wrong. I was really wondering if anyone was working on a set of C++ tests, similar to the Python tests. Thanks, Mary -Original Message- From: William Henry [mailto:whe...@redhat.com] Sent: Wednesday, January 02, 2013 12:51 PM To: proton@qpid.apache.org Cc: dpie...@redhat.com Subject: Re: Language example apps... Hi Mary, It is my understanding that the existing C++ examples should work because the proton based C++ API the Qpid proper API with the proton C API under the covers. That said, I'm not sure what testing has been done to make sure this is true. Also it would seem that perhaps there might be two sets of examples (?). i.e. What happens to old style addresses in the new proton enabled C++ API? Do the still just work? Can I mix simple proton addressing with the more complex previous addressing that allowed us to build exchanges and queues? William - Original Message - > > In terms of depth, I'm concerned that deep examples will be > > difficult/impossible to maintain well in 5 different languages (6 if > > we do something with C++). > > Above you mentioned the possibility of C++ examples. Is anyone > currently working on creating C++ examples? > > Thanks, > Mary > > -Original Message- > From: Darryl L. Pierce [mailto:dpie...@redhat.com] > Sent: Friday, November 30, 2012 4:05 PM > To: proton@qpid.apache.org > Subject: Re: Language example apps... > > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: > > On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce > wrote: > > > > > Last week Justin asked me to take a look at the examples for > > > Proton across language bindings. What I found are the following: > > > > > > C Python Ruby Perl > > > Mailbox (Raw API)[ ] [X] [X] [ ] > > > Send/Receive (Messenger classes) [ ] [X] [X] [X] > > > Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] > > > > > > > We also have a PHP binding and it has some examples also. > > Yeah, sorry to forget that. > > > What came out of the discussion was that there's a definite lack of > > > depth with the examples. The Mailbox demo is a nice, specific > > > example of stored messaging. The Send/Receive examples show very > > > simple point-to-point messaging. > > > > > > But what else should be included in examples? The first thing that > > > comes to mind is an example demonstrating subscriptions. > > > > > > Ideas? > > > > > > > A couple of random thoughts off the top of my head... > > > > I think the focus for the dynamic language bindings should really be > > messenger based examples. I would say it's really not worth having > > non messenger examples for the dynamic languages, particularly as > > those kinds of examples are much more involved and maintaining > > duplicate examples involves some significant maintenance effort. I > > would rather see a very well maintained/structured C example for the > > non messenger stuff. In fact I'd go so far as to say we shouldn't > > bother exposing the non messenger APIs through the bindings at all, > > with the exception of python for testing purposes of course. To be > > clear I'm not opposed to exposing them, I just don't think there is > > any demand at this point and I think it just creates unnecessary > > work until there is. > > > > In terms of depth, I'm concerned that deep examples will be > > difficult/impossible to maintain well in 5 different languages (6 if > > we do something with C++). What I'd suggest we start with is a > > basic, well thought out, but simple messenger based example geared > > towards getting people started, and strive to keep that consistent > > and up to date across all the bindings. I'd keep deep scenarios to > > one language only (at least at first), choosing whichever seems most > > appropriate for that particular deep scenario. > > If we keep the languages as consist as possible across the bindings, > then one language doing a deep example and others doing more general > examples should be workable. Assuming the one language is as easy to > understand for someone not familiar with it to follow. > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > > > >
Re: Language example apps...
? I don't think anyone is suggesting it wouldn't be appropriate. Were my semantics such that I added some confusion? William - Original Message - > Why would examples in every normative language not be appropriate? > Synchronization may be an issue, but wouldn't examples be easily > synchronized with language-specific API updates? > > > On Wed, Jan 2, 2013 at 12:50 PM, William Henry > wrote: > > > Hi Mary, > > > > It is my understanding that the existing C++ examples should work > > because > > the proton based C++ API the Qpid proper API with the proton C API > > under > > the covers. > > > > That said, I'm not sure what testing has been done to make sure > > this is > > true. > > > > Also it would seem that perhaps there might be two sets of examples > > (?). > > i.e. What happens to old style addresses in the new proton enabled > > C++ API? > > Do the still just work? Can I mix simple proton addressing with the > > more > > complex previous addressing that allowed us to build exchanges and > > queues? > > > > William > > > > - Original Message - > > > > In terms of depth, I'm concerned that deep examples will be > > > > difficult/impossible to maintain well in 5 different languages > > > > (6 > > > > if > > > > we do something with C++). > > > > > > Above you mentioned the possibility of C++ examples. Is anyone > > > currently > > > working on creating C++ examples? > > > > > > Thanks, > > > Mary > > > > > > -Original Message- > > > From: Darryl L. Pierce [mailto:dpie...@redhat.com] > > > Sent: Friday, November 30, 2012 4:05 PM > > > To: proton@qpid.apache.org > > > Subject: Re: Language example apps... > > > > > > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: > > > > On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce > > > wrote: > > > > > > > > > Last week Justin asked me to take a look at the examples for > > > > > Proton > > > > > across language bindings. What I found are the following: > > > > > > > > > > C Python Ruby Perl > > > > > Mailbox (Raw API)[ ] [X] [X] [ ] > > > > > Send/Receive (Messenger classes) [ ] [X] [X] [X] > > > > > Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] > > > > > > > > > > > > > We also have a PHP binding and it has some examples also. > > > > > > Yeah, sorry to forget that. > > > > > > > What came out of the discussion was that there's a definite > > > > lack of > > > > > depth with the examples. The Mailbox demo is a nice, specific > > > > > example of stored messaging. The Send/Receive examples show > > > > > very > > > > > simple point-to-point messaging. > > > > > > > > > > But what else should be included in examples? The first thing > > > > > that > > > > > comes to mind is an example demonstrating subscriptions. > > > > > > > > > > Ideas? > > > > > > > > > > > > > A couple of random thoughts off the top of my head... > > > > > > > > I think the focus for the dynamic language bindings should > > > > really > > > > be > > > > messenger based examples. I would say it's really not worth > > > > having > > > > non > > > > messenger examples for the dynamic languages, particularly as > > > > those > > > > kinds of examples are much more involved and maintaining > > > > duplicate > > > > examples involves some significant maintenance effort. I would > > > > rather > > > > see a very well maintained/structured C example for the non > > > > messenger > > > > stuff. In fact I'd go so far as to say we shouldn't bother > > > > exposing > > > > the non messenger APIs through the bindings at all, with the > > > > exception > > > > of python for testing purposes of course. To be clear I'm not > > > > opposed > > > > to exposing them, I just don't think there is any demand at > > > > this > > > > point > > > > and I think it just creates unnecessary work until there is. > > > > > > > > In terms of depth, I'm concerned that deep examples will be > > > > difficult/impossible to maintain well in 5 different languages > > > > (6 > > > > if > > > > we do something with C++). What I'd suggest we start with is a > > > > basic, > > > > well thought out, but simple messenger based example geared > > > > towards > > > > getting people started, and strive to keep that consistent and > > > > up > > > > to > > > > date across all the bindings. I'd keep deep scenarios to one > > > > language > > > > only (at least at first), choosing whichever seems most > > > > appropriate > > > > for that particular deep scenario. > > > > > > If we keep the languages as consist as possible across the > > > bindings, > > > then > > > one language doing a deep example and others doing more general > > > examples > > > should be workable. Assuming the one language is as easy to > > > understand for > > > someone not familiar with it to follow. > > > > > > -- > > > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > > > Delivering value year after year. > > > Red Hat ranks #1 in val
Re: Language example apps...
No problem Hinton. ;-) -William - Original Message - > Thanks Henry, > I asked my question wrong. > I was really wondering if anyone was working on a set of C++ tests, > similar to the Python tests. > Thanks, > Mary > > -Original Message- > From: William Henry [mailto:whe...@redhat.com] > Sent: Wednesday, January 02, 2013 12:51 PM > To: proton@qpid.apache.org > Cc: dpie...@redhat.com > Subject: Re: Language example apps... > > Hi Mary, > > It is my understanding that the existing C++ examples should work > because the proton based C++ API the Qpid proper API with the proton > C API under the covers. > > That said, I'm not sure what testing has been done to make sure this > is true. > > Also it would seem that perhaps there might be two sets of examples > (?). i.e. What happens to old style addresses in the new proton > enabled C++ API? Do the still just work? Can I mix simple proton > addressing with the more complex previous addressing that allowed us > to build exchanges and queues? > > William > > - Original Message - > > > In terms of depth, I'm concerned that deep examples will be > > > difficult/impossible to maintain well in 5 different languages (6 > > > if > > > we do something with C++). > > > > Above you mentioned the possibility of C++ examples. Is anyone > > currently working on creating C++ examples? > > > > Thanks, > > Mary > > > > -Original Message- > > From: Darryl L. Pierce [mailto:dpie...@redhat.com] > > Sent: Friday, November 30, 2012 4:05 PM > > To: proton@qpid.apache.org > > Subject: Re: Language example apps... > > > > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote: > > > On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce > > wrote: > > > > > > > Last week Justin asked me to take a look at the examples for > > > > Proton across language bindings. What I found are the > > > > following: > > > > > > > > C Python Ruby Perl > > > > Mailbox (Raw API)[ ] [X] [X] [ ] > > > > Send/Receive (Messenger classes) [ ] [X] [X] [X] > > > > Send/Receive (Non-Messenger) [X] [ ] [ ] [ ] > > > > > > > > > > We also have a PHP binding and it has some examples also. > > > > Yeah, sorry to forget that. > > > > > What came out of the discussion was that there's a definite lack > > > of > > > > depth with the examples. The Mailbox demo is a nice, specific > > > > example of stored messaging. The Send/Receive examples show > > > > very > > > > simple point-to-point messaging. > > > > > > > > But what else should be included in examples? The first thing > > > > that > > > > comes to mind is an example demonstrating subscriptions. > > > > > > > > Ideas? > > > > > > > > > > A couple of random thoughts off the top of my head... > > > > > > I think the focus for the dynamic language bindings should really > > > be > > > messenger based examples. I would say it's really not worth > > > having > > > non messenger examples for the dynamic languages, particularly as > > > those kinds of examples are much more involved and maintaining > > > duplicate examples involves some significant maintenance effort. > > > I > > > would rather see a very well maintained/structured C example for > > > the > > > non messenger stuff. In fact I'd go so far as to say we shouldn't > > > bother exposing the non messenger APIs through the bindings at > > > all, > > > with the exception of python for testing purposes of course. To > > > be > > > clear I'm not opposed to exposing them, I just don't think there > > > is > > > any demand at this point and I think it just creates unnecessary > > > work until there is. > > > > > > In terms of depth, I'm concerned that deep examples will be > > > difficult/impossible to maintain well in 5 different languages (6 > > > if > > > we do something with C++). What I'd suggest we start with is a > > > basic, well thought out, but simple messenger based example > > > geared > > > towards getting people started, and strive to keep that > > > consistent > > > and up to date across all the bindings. I'd keep deep scenarios > > > to > > > one language only (at least at first), choosing whichever seems > > > most > > > appropriate for that particular deep scenario. > > > > If we keep the languages as consist as possible across the > > bindings, > > then one language doing a deep example and others doing more > > general > > examples should be workable. Assuming the one language is as easy > > to > > understand for someone not familiar with it to follow. > > > > -- > > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > > Delivering value year after year. > > Red Hat ranks #1 in value among software vendors. > > http://www.redhat.com/promo/vendor/ > > > > > > > > > > >
Proton Messenger and the Request/Response pattern
I'd like to start a discussion on how, from an API perspective,
applications can use the request/response pattern. If we get this
right, we will remove a significant barrier to adoption of AMQP.
Middleware messaging systems typically do a poor job of supporting this
pattern. The Qpid APIs are quite lacking in this regard (requester
creates and subscribes to a temporary queue with a _unique_ name and
places this name in the reply-to field).
Proton Messenger supports request/reply (see
examples/messenger/$LANG/{client,server}) as follows:
The requester (client) has to put _something_ into the request message's
reply_to field. It also sets the correlation_id field if it needs to
dispatch multiple responses. The responder (server) must copy the
request message's reply_to field to the response message's address field
and also copy the correlation_id.
This API is good for the case where the client wants the response to go
to a third party. In this case the reply_to is well understood to be
the address of the third party receiver. However in the more common
case where the response is intended to come back to the client, it's not
clear at all what to put in the reply_to field.
I propose that we allow the client to simply say
request_msg.reply_expected(cid)
(I added the correlation_id argument because it's almost always going to
be needed). Further, the server could use
reply_msg.in_reply_to(request_msg)
which would take care of the addresses and the correlation_id. It also
provides a place to report an error if a request cannot be replied to
(absent or invalid reply_to address) rather than force each server
implementer to code this check.
Thoughts?
-Ted
Re: Proton Messenger and the Request/Response pattern
- Original Message -
> I'd like to start a discussion on how, from an API perspective,
> applications can use the request/response pattern. If we get this
> right, we will remove a significant barrier to adoption of AMQP.
>
> Middleware messaging systems typically do a poor job of supporting
> this
> pattern. The Qpid APIs are quite lacking in this regard (requester
> creates and subscribes to a temporary queue with a _unique_ name and
> places this name in the reply-to field).
>
> Proton Messenger supports request/reply (see
> examples/messenger/$LANG/{client,server}) as follows:
>
> The requester (client) has to put _something_ into the request
> message's
> reply_to field. It also sets the correlation_id field if it needs to
> dispatch multiple responses. The responder (server) must copy the
> request message's reply_to field to the response message's address
> field
> and also copy the correlation_id.
>
> This API is good for the case where the client wants the response to
> go
> to a third party. In this case the reply_to is well understood to be
> the address of the third party receiver. However in the more common
> case where the response is intended to come back to the client, it's
> not
> clear at all what to put in the reply_to field.
>
> I propose that we allow the client to simply say
>
> request_msg.reply_expected(cid)
Could you even block here with:
reply_msg = request_msg.reply_expected(cid)
You can have a default parameter that indicates blocking. And you could
request_msg.reply_expected(cid, FALSE)
and then do the usual check for incoming messages etc.
>
> (I added the correlation_id argument because it's almost always going
> to
> be needed). Further, the server could use
>
> reply_msg.in_reply_to(request_msg)
>
> which would take care of the addresses and the correlation_id. It
> also
> provides a place to report an error if a request cannot be replied to
> (absent or invalid reply_to address) rather than force each server
> implementer to code this check.
Yeah, that's nice too. I see your point. I'm not sure if all messaging purists
will agree. But it makes sense to me that we need something to handle this
common use case more effectively.
William
>
> Thoughts?
>
> -Ted
>
>
Re: Proton Messenger and the Request/Response pattern
On 01/02/2013 02:39 PM, William Henry wrote:
- Original Message -
I'd like to start a discussion on how, from an API perspective,
applications can use the request/response pattern. If we get this
right, we will remove a significant barrier to adoption of AMQP.
Middleware messaging systems typically do a poor job of supporting
this
pattern. The Qpid APIs are quite lacking in this regard (requester
creates and subscribes to a temporary queue with a _unique_ name and
places this name in the reply-to field).
Proton Messenger supports request/reply (see
examples/messenger/$LANG/{client,server}) as follows:
The requester (client) has to put _something_ into the request
message's
reply_to field. It also sets the correlation_id field if it needs to
dispatch multiple responses. The responder (server) must copy the
request message's reply_to field to the response message's address
field
and also copy the correlation_id.
This API is good for the case where the client wants the response to
go
to a third party. In this case the reply_to is well understood to be
the address of the third party receiver. However in the more common
case where the response is intended to come back to the client, it's
not
clear at all what to put in the reply_to field.
I propose that we allow the client to simply say
request_msg.reply_expected(cid)
Could you even block here with:
reply_msg = request_msg.reply_expected(cid)
You can have a default parameter that indicates blocking. And you could
request_msg.reply_expected(cid, FALSE)
and then do the usual check for incoming messages etc.
I really like this suggestion. The blocking variant is dirt simple and
you don't even need to supply a correlation_id. It can be hidden
beneath the API.
I do think there may be a cleaner syntax/naming for this though.
An alternate syntax for the client side might be to provide an
alternative to "put" like "put_request" that annotates the message
appropriately for request/response and returns the correlation_id.
"send_request" could be the blocking variant.
(I added the correlation_id argument because it's almost always going
to
be needed). Further, the server could use
reply_msg.in_reply_to(request_msg)
which would take care of the addresses and the correlation_id. It
also
provides a place to report an error if a request cannot be replied to
(absent or invalid reply_to address) rather than force each server
implementer to code this check.
Yeah, that's nice too. I see your point. I'm not sure if all messaging purists
will agree. But it makes sense to me that we need something to handle this
common use case more effectively.
William
Thoughts?
-Ted
