jdev - 2022-03-11

I think I asked this before but I can't remember or find if it was answered or if we went off on a tangent: is anyone aware of any non-standard uses of message types in the wild? Ie. type="foo" or an absent type attribute being treated different from type="normal"?

I'd expect that you find those plently (and probably mostly) in custom non-federated setups. Judging from the amount of Smack questions I see where people set a custom type

e.g., type=avatar

*sigh* yah, that's kid of what I was expecting but I wanted confirmation. Thanks!

I'm not sure that I care to support such things, but if we do it helps me decide on an issue that I'm struggling with so it's good info to have.

fwiw Smack does not support custom message types, but IIRC xmppframework does. so that happens is that people aim for iOS first, because that's where the money is I suppose, and then later want to extend over to Android

that said, I am not strictly opposed to supporting arbitrary types in smack. I always try to follow the specs, which IIRC allow for custom types. But someone just hast to implement it (or pay someone - doesn't have to be me - to implement it)

At least for message the specs don't allow it, I think. Anything other than a defined type is the same as type="normal"

could be a interpreation thing

I think In interpreted the spec as "everything not defined is routed as 'normal'", and assumed that ideally users also want to be able to retrieve the actual on the wire value (and not have it replaced with 'normal')

> If included, the 'type' attribute MUST have one of the following > values

yeah, could very well be that the spec is not really clear in this regard, or that the spec authors intention was to keep a loophole open for non-standard values for type

But yah, should I always keep the wire value (and just treat it as "normal" when selecting a handler) or should I replace it with "normal" when we decode the wire value into our own representation is what I'm deciding (the user could still implement their own decoding to preserve the wire value, it would jsut be an extra hoop they'd have to jump through)

https://mellium.im/issue/272 in case you're interested