jdev - 2020-09-01


  1. flow

    debacle, i'd probably simply mimic the pattern of xep335 for csv and init files, and i'd potentially add an 'id' attribute to the element, which identifies the payload in case there are multiple payloads of the same kind (akin to data form's FORM_FIELD, but not within the payload)

  2. flow

    debacle, i'd probably simply mimic the pattern of xep335 for csv and ini files, and i'd potentially add an 'id' attribute to the element, which identifies the payload in case there are multiple payloads of the same kind (akin to data form's FORM_FIELD, but not within the payload)

  3. debacle

    flow OK, sounds good. In my case there will be only one payload, so this is easy.

  4. pep.

    Don't forget to namespace :)

  5. debacle

    MattJ Why does a container for JSON exist, but not for other text types? Does "XEP-1521: Text Containers" make sense? <text xmlns="urn:xmpp:text:0" type="text/csv"> Aaron,Titus Andronicus The Abbott of Westminster,Richard II Lord Abergavenny,Henry VIII </text> With type = (whatever boils down to text in the MIME universe), maybe defaulting to "text/plain"? Or would people start to use it for multipart "application/vnd.ms-powerpoint"?

  6. jonas’

    debacle, you could also go with standard <body/> and set Content-Type via XEP-0131

  7. Kev

    debacle: The reason for JSON containers was that lots of people shove things in body that really shouldn't be there, and it's usually JSON.

  8. Kev

    And there was a hope that by providing a XEP, libraries would support it and it would be as easy to do something that was less wrong as it was to do the wrong thing.

  9. Kev

    *really* the sensible thing to do is to use your own element in your own namespace when shifting stuff around that's only understood by your own application.

  10. jonas’

    that’s true

  11. pep.

    So the obvious solution is to convert everything to JSON and use 335!

  12. Kev

    ...it's less bad than shoving things in the body :)

  13. jonas’

    noooooooooooo

  14. pep.

    :D

  15. pep.

    debacle: I imagine you use slix? it's quite easy to create a custom container based on the 335 module

  16. pep.

    Change the NS, the tag name and you're almost done

  17. pep.

    you can even do validation directly in there if you want

  18. pep.

    (just as the 335 slix module does)

  19. flow

    there's also xep432, but it's specific to json. I do wonder, just like debacle, if this shouldn't be applied to other text types

  20. debacle

    pep. libstrophe! ;-)

  21. MattJ

    The problem is that CSV is a terrible idea for interop

  22. debacle

    Not much worse than JSON ;-)

  23. MattJ

    JSON at least has just the RFC and the version everyone uses

  24. debacle

    RFC 4180. But anyway, this is about legacy/proprietary applications. It's not the scope of XMPP to fix them, I assume.

  25. Kev

    It's 432 I was thinking of, thanks flow.

  26. MattJ

    Honestly best to just use a custom element in a custom namespace

  27. Kev

    ^

  28. MattJ

    I was going to ask about 432 recently

  29. pep.

    I still don't get 432 :/

  30. pep.

    Why..

  31. debacle

    kev MattJ I see. At least, that is easy.

  32. MattJ

    It's renamed and vastly simplified (I approve), but now it's just a wrapper around JSON containers that adds a datatype field and disco

  33. pep.

    Yo dawg I know you like containers so I put a container in your container

  34. MattJ

    Is it needed? Or better to add these to JSON containers?

  35. MattJ

    The original UDT was too specific and extensive, but the current XEP doesn't seem so

  36. pep.

    funnily the shortname is still udt

  37. debacle

    OK, I will combine 0295 and 0335 then ;-) <json xmlns="urn:xmpp:json:0"> { "type": "text/csv", "data": "Aaron,Titus Andronicus..." } </json>

  38. pep.

    :x

  39. pep.

    Why

  40. debacle

    (kidding)

  41. pep.

    Ah sorry..

  42. flow

    pep.> I still don't get 432 :/ I think the idea was that xmpp client libraries provide a common API to get/set the textual data

  43. flow

    compared to custom elements, this would have the advantage that you don't need to fidle with whatever you need to do to plug support for those custom elements into the library you are using

  44. flow

    so I see a certain appeal in that

  45. jonas’

    the textual data? ITYM CDATA or JSON data

  46. jonas’

    (and even CDATA I would find confusing, because the point would be to take JSON, not strings, via the API)

  47. flow

    hmm? textual data / char data, should be the same here

  48. flow

    on the xmpp library api surface it's just strings/textual data/character data

  49. jonas’

    I sure hope not

  50. flow

    if the string is json, csv, or whatever does not matter to the string representation

  51. jonas’

    then it’s no gain

  52. pep.

    flow, and that would already be out of spec for 432 as I understand it

  53. jonas’

    on the API surface it should be JSON

  54. flow

    pep., yes, iirc the first version of the protoxep for xep432 was different

  55. flow

    that UDT (?) thingy

  56. pep.

    I'd rather teach devs how to use the library rather than having them use a one-size-fits-all thing that doesn't fit all

  57. flow

    that would allow your library to provider setters/getters like setter: setPayload(Stanza stanza, Type type, String id, String payload) → setPayload(stanza, Type.CSV, "my-data", "foo, bar, baz") getter: String getPayload(Stanza stanza, Type type, String id) → getPayload(stanza, Type.CSV, "my-data")

  58. flow

    that would allow your library to provide setters/getters like setter: setPayload(Stanza stanza, Type type, String id, String payload) → setPayload(stanza, Type.CSV, "my-data", "foo, bar, baz") getter: String getPayload(Stanza stanza, Type type, String id) → getPayload(stanza, Type.CSV, "my-data")

  59. jonas’

    flow, but not in '432

  60. flow

    jonas’, I know, I think that was one goal of UDT

  61. jonas’

    ok

  62. flow

    pep., again, that strikes me as something that does not exclude each other

  63. flow

    Smack has had JiveProperties since nearly 20 years now, and from what I can tell it is very well accepted by the users, as it allows to transport arbitrary data easily, without having to fiddle with adding custom extension elements

  64. flow

    I was that involved in UDT, but I think I liked the idea. not sure why it got cut down to json only

  65. flow

    I was not that involved in UDT, but I think I liked the idea. not sure why it got cut down to json only

  66. debacle

    Btw. I wonder, whether this structure is correct? <iq id="1" type="set"> <pubsub xmlns="http://jabber.org/protocol/pubsub"> <publish node="mynode"> <item> <json xmlns="urn:xmpp:json:0"> {&quot;foo&quot;:123} </json> </item> </publish> </pubsub> </iq> It works well, at least, but that does not mean anything.

  67. jonas’

    lgtm, but I always get confused by pubsub nesting

  68. debacle

    jonas’ That's why I ask ;-) But it seems things end up in PEP as intended.

  69. jonas’

    then it’s probably ok :)

  70. rion

    If anyone uses QCA for cryptography, I just added DTLS support there. So basically ready for Jingle stuff.

  71. Zash

    /react najs!

  72. jonas’

    react.js?

  73. Zash

    I'd rather not