Fwd: Re: Proton C++ binding: cases where value may not be present not handled correctly where methods return std::string

[Kim van der Riet <ki...@redhat.com>]

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 <ac...@redhat.com>
Organization: Red Hat
To: Andrew Stitcher <as...@redhat.com>, Kim van der Riet 
<ki...@redhat.com>, Clifford Jansen <cj...@redhat.com>
CC: Justin Ross <jr...@redhat.com>, messaging@redhat.com

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org