On 04.02.2015 12:45, Kevin Smith wrote: > On 4 Feb 2015, at 11:37, Florian Schmaus <[email protected]> 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
