XSF Discussion - 2018-11-23


  1. Ge0rG

    is it illegal to send a presence update to multiple joined MUCs using the same szanza id?

  2. jonas’

    maybe

  3. jonas’

    It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally.

  4. jonas’

    you’re fulfilling neither of those .. requirements .. in that case

  5. ralphm

    But treating ids as unique in its own is bound to give you grief, so better take the addressing into account.

  6. Ge0rG

    oh god who wrote that code? `if (packetID != null ? !packetID.equals(packet.packetID) : packet.packetID != null) {`

  7. ralphm

    Oops

  8. Ge0rG

    So I was just sending the same presence packet to multiple @to MUCs, to my own participant JID, but it turns out only to work randomly. And from the logs it seems to have uncovered another unrelated bug.

  9. Ge0rG

    Oh my. You can't send-change-send the same Packet object in smack3.

  10. ralphm

    I think there's an assumption that clients don't repeat stanza ids on outbound traffic, but can't find the reference. As a recipient, you probably want to associate with the sender and recipient address. I'm pretty sure there are a lot of exploitable/buggy implementations.

  11. ralphm

    *especially* with MUC

  12. Ge0rG

    the problem is that I give smack3 a reference to the Packet object, not a copy. So by changing the JID, all of the enqueued references are sent to the same JID

  13. ralphm

    Haha

  14. Ge0rG

    which explains why the MUC status update happens randomly in a subset of MUCs

  15. ralphm

    That's a bad idea to try anyway

  16. Ge0rG

    because race conditions between enqueue and send thread.

  17. Ge0rG

    flow: does smack4 create a local copy of a Packet that you pass to sendPacket()?

  18. ralphm

    Yeah, once you send a stanza, don't touch it. I'm many libraries and languages.

  19. ralphm

    In

  20. Ge0rG

    See, I was just trying to be smart and to re-use resources.

  21. Ge0rG

    also, should I set the same priority for MUCs as for my normal presence, or just keep it at 0?

  22. jonas’

    aioxmpp would behave the same

  23. Ge0rG

    the nicest thing is, when I was debugging the user report, single-stepping through the code made the bug vanish.

  24. jonas’

    but it also has a convenient way to duplicate a stanza, so...

  25. jonas’

    oh, a heisenbug

  26. ralphm

    No, presence to MUC is directed and you can do whatever

  27. Ge0rG

    And I was short of telling the user they are crazy. After they provided logs, I got suspicious, because the 0198 logger told me the packet is not being counted, which should never happen after <enable/>

  28. flow

    Ge0rG, no, that wouldn't be sensible, as you had to pay the copy operation for every sendStanza() whereas I'd assume only a minority calls would benefit from it

  29. flow

    but Presence has a copy constructor

  30. Ge0rG

    flow: not in smack3 ;)

  31. flow

    yeah, I can't really comment on five year old code

  32. Ge0rG

    flow: it might be a good idea then to add a @warning to the docs, telling to never submit the same Packet twice.

  33. Ge0rG

    C++ has some sophisticated ownership management cruft around that. I don't think there is any way to enforce that in Java though

  34. flow

    I'm not sure if it justifies a warning since it is common for sink like functions that you hand over ownership of the provided arguments, but a note to the javadoc sure can't hurt

  35. Ge0rG

    it's not going to prevent people from doing what I did, leading to hard to debug issues. But after they realize what they did wrong, they'll see the message in the docs and feel even more ashamed.

  36. jonas’

    hah

  37. flow

    patches welcome ;)

  38. Ge0rG

    I had to look up the semantics of Queue.contains() and single-step through Packet.equals() to be enlighted

  39. Seve

    Hey guys, I couldn't attend the meeting yesterday unfortunately, but congratulations to everyone and thank you very much Alex :)

  40. jonas’

    Seve, congratulations to you, too :)

  41. Ge0rG

    and congratulations to jonas’ as well!

  42. jonas’

    thanks, but didn’t we have that yesterday or did I miss something? ;-)

  43. Ge0rG

    jonas’: I think I didn't congratulate you specifically.

  44. jonas’

    ah, well

  45. Seve sends happy stanzas for everyone.

  46. Ge0rG now wonders what the XML looks like for that

  47. Zash

    User Mood?

  48. Zash

    `<happy xmlns='http://jabber.org/protocol/mood'/>`

  49. jonas’

    <x xmlns="jabber:x:oob"><url>https://www.youtube.com/watch?v=ZbZSe6N_BXs</url></x>?

  50. Zash

    Lol ❌

  51. Ge0rG

    jonas’: I'm disappointed in your taste of music.

  52. Ge0rG

    (I also kind of had expected https://www.youtube.com/watch?v=DLzxrzFCyOs)

  53. jonas’

    Ge0rG, who says that this is my taste of music?

  54. Ge0rG

    jonas’: I considered it would be too meta if you implied that that was Seve's music taste.

  55. jonas’

    no, I don’t know his music taste :)

  56. Seve

    I like human music

  57. Ge0rG

    as opposed to computer-generated music?

  58. Ge0rG

    what about music written by humans and performed by computers? (the 386dx project comes to mind)

  59. Seve

    It was a reference to a show called Rick and Morty :D https://www.youtube.com/watch?v=S1jWdeRKvvk

  60. flow

  61. jonas’

    empty message is empty