Wanted to get this API conversation on the public list. The AMQP protocol treats all properties as "optional" so on the wire properties can be "missing". Other APIs can represent this distinction, e.g. python returns None for missing and "" for empty string.
The C++ API repreents properties like reply-to as a std::string, which has no way of representing "missing". C++ returns the same empty string value for missing reply-to and reply-to="" Kim's interop testing verifies whether we correctly propagate the missing/empty distinction so he can't port (some of) his tests to C++. Does this matter? astitcher argues that there is no semantic difference between missing and "" for values like reply-to and we shouldn't complicate the API. I see where he's coming from, but I still argue that ... On Wed, 2016-08-24 at 19:20 +0100, Alan Conway wrote: > On Wed, 2016-08-24 at 13:51 -0400, Andrew Stitcher wrote: > > > > On Wed, 2016-08-24 at 18:09 +0100, Alan Conway wrote: > > > > > > > > > ... > > > There is a semantic difference in the AMQP specification. > > > > Well, what is the difference (semantically)? > > > > A message with no correlation-id is not the same as a message with a > correlation-id of the empty string or the integer 0. 0 might be a > real > correlation ID in an integer sequence. "" would be a silly > correlation- > id but we don't choose them so we can't assume it won't ever be used. > > A message with no reply-to address is not (on the wire) the same as a > message with reply-to="". It would be daft to design a system where > "" > is a legal address, but we don't control what the remote endpoint > does. > It is conceivable that somewhere, reply-to="" means reply to the node > called "" not don't reply. > > C++ does not have much of a notion of "missing" but python does with > None. It's conceivable in an all-python system that someone makes an > ill-advised assumpiton that `"" != None` in an AMQP property. I'm not > saying it is a good idea to do that, just that C++ needs to be able > to > talk to anything that speaks AMQP, even if it does things that are > not > a great idea. > > Another case to consider is a mid-tier server that forwards messages. > It might be bad if it "fills in" default values as a side effect. > Even > if there's no semantic problem it makes messages bigger and otherwise > is just doing things the user didn't ask for. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
