On Thu, 2015-06-11 at 13:40 +0100, Gordon Sim wrote: > On 06/11/2015 01:11 PM, aconway wrote: > > I disagree. An empty string is a perfectly legal value for a > > string. If > > the spec wants to assign special meaning to particular values of a > > property that needs to be stated. Of course, like you, I personally > > would not use an empty string as an identifier but as an > > implementor of > > an inter-operable spec I think we have to take the large view: > > *any* > > legal value of a parameter has to be considered equal unless the > > spec > > clearly states otherwise. > > If a name field is populated with an empty string, that to me is the > same as not supplying a name. An empty string is a legal encoding, > but > in my view it does not supply a value at all. (It is not like say 0 > which may be the default but is clearly a value in its own right). >
It is exactly like 0, a perfectly legal value that is often abused to mean something special. "" is a legal string literal in every language I know of. It can be used as a key in a map or hash table. It can be compared with other strings. There is no string operation in any language I know that will throw NotAString if you apply it to "". > However, from the practical point of view... This is very practical. Interoperability is about agreeing on a type system. A "type" defines a range of legal values. The AMQP type system includes empty string and 0-length binaries as legal values for those types. We absolutely cannot treat any legal value in an exceptional way unless that is clearly mandated by the spec. > [...] > > Quote me the spec, this is a mater of law not opinion ;) > > I suspect that the sending of an empty string for a multi-frame > message > is entirely unintentional on the part of Apollo. I suspect it is a > bug > in Apollo or in the proton-j version/path it uses. That should be > confirmed and an appropriate JIRA raised That's fine for Apollo but irrelevant for proton. The first law of interoperability is "be strict with what you send, be forgiving with what you receive." To me that means that we should never *send* an empty delivery tag, but we should accept one unless the spec clearly states that it is illegal for anyone to ever send one. I see no such clear statement. . > > Proton-c should also not crash on receiving an empty (or null) > delivery > id. Beyond that I'm not overly concerned how it handles the empty > string > case.
