jdev - 2022-03-11

  1. Sam

    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"?

  2. flow

    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

  3. flow

    e.g., type=avatar

  4. Sam

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

  5. Sam

    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.

  6. flow

    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

  7. flow

    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)

  8. Sam

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

  9. flow

    could be a interpreation thing

  10. flow

    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')

  11. Sam

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

  12. flow

    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

  13. Sam

    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)

  14. Sam

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