[Standards] XMPP APIs and duplicate extension elements

Florian Schmaus flo at geekplace.eu
Fri Feb 6 14:53:50 UTC 2015


On 04.02.2015 12:45, Kevin Smith wrote:
> On 4 Feb 2015, at 11:37, Florian Schmaus <flo at geekplace.eu> wrote:
>> This means that in order to allow retrieval
>> of *all* elements, XMPP APIs need to provide a method like
>>
>>
>> List<Element> Stanza.getExtensions(String name, String namespace)
>>
>>
>> but a quick survey did not reveal any API that actually does this.
> 
> http://swift.im/git/swift/tree/Swiften/Elements/Stanza.h#n47

Uh, How could I forget looking at Swiften. :)

>> I like to propose that a future RFC (or another normative spec) forbids
>> duplicate extension elements. Now I know this is likely a controversial
>> proposal. But please have a look my arguments first:
>>
>> - Most APIs don't support duplicate extension elements, this leads to
>> the conclusion that nobody noticed that they are not supported, i.e.
>> nobody is missing that feature.
> 
> I’m sure there are some client libraries with this bug, but certainly not all.
> 
>> - They make implementations more complex, in terms of LOC (at least if
>> you want to support fast lookup of extension element a stanza has).
> 
> I think it costs Swiften about 20 LoC. Just provide an ‘I know there’s only one of this type, so give me it’ call as well as the ‘give me all of them’ call, and you’re pretty much done.

Well, I kind of expected this reply. And of course this is a sensible
way to design the API.

Smack does use an MultiMap for the extension elements. But it still
feels like a design flaw, that if one wants fast lookups for the
extension elements, we have to create an extra data structure to hold
possible duplicate extension elements, that (and that sure is only my
impression) are seldom used in XMPP.

Anyway, I hope to have at least made some developers aware of the situation.

- Florian




More information about the Standards mailing list