This topic, which concerns the C++ API, is being forwarded as it
deserves broader coverage in the community. Please weigh in if you have
an opinion!
-------- Forwarded Message --------
Subject: Re: Proton C++ binding: cases where value may not be present
not handled correctly where methods return std::string
Date: Wed, 24 Aug 2016 18:09:43 +0100
From: Alan Conway <[email protected]>
Organization: Red Hat
To: Andrew Stitcher <[email protected]>, Kim van der Riet
<[email protected]>, Clifford Jansen <[email protected]>
CC: Justin Ross <[email protected]>, [email protected]
On Wed, 2016-08-24 at 12:23 -0400, Andrew Stitcher wrote:
On Wed, 2016-08-24 at 11:45 -0400, Kim van der Riet wrote:
>
> In the Proton C++ binding, several methods return message headers
> as
> std::string which may or may not be present. If the header is not
> present, then the method returns an empty string, but this is not
> distinguishable from the (perhaps trivial) case where the header
> is
> actually present as an empty string.
Briefly, I want to query whether there is in fact a *semantic*
difference between no header and empty string (assuming all of these
headers can only be a string, well utf8, value).
There is a semantic difference in the AMQP specification.
It is an utterly stupid and pointless difference, no sensible system
should use or rely on it, but there it is.
As an AMQP interop library, we have no control over what our users will
try to interop with or how other endpoints will use the spec. There are
a lot of not-sensible systems out there so IMO if AMQP allows it, we
have to be able to cope with it.
So I would favour keeping the existing simple string API for sensible
users and adding extra bool has_foo() tests for corner cases. We can
document that it is a bad idea to use them unless you have a particular
interop problem to solve.
If there is no real application distinction between no header and
empty
string, even if Python and JMS can distinguish, I don't see this as
an
important application API issue.
So the question for the application writes out there - Do you care if
there is an empty subject/to/etc. rather than there just not being
one
at all?
>
>
> Both the JMS and Python bindings handle this case using null /
> None
> respectively where there is no header present, but for the C++
> binding
> this is not currently distinguishable. This is causing the failure
> of
> some of the qpid-interop-tests where the empty string is used as
> one
> of
> the test cases.
>
>
> I have quickly looked through the API in message.{hpp,cpp}, these
> are
> the (possibly) affected methods, which all except one return
> std::string, and return an empty string when the underlying proton
> call
> returns a null:
>
> to()
> address()
> reply_to()
> subject()
> content_type()
> content_encoding()
> group_id()
> reply_to_group_id()
> correlation_id() - returns default c'tor on proton::message_id,
> which
> is
> uint64_t(0).
This last as Alan has pointed out can be a string/binary or integer
so
the default should not be 0 but null.
I think the others can only be strings (but I didn't check the
protocol
spec).
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
