jdev - 2020-06-10

  1. vasuta

    Hello

  2. vasuta

    Hello world

  3. Link Mauve

    “20:53:00 flow> we could add an optional feature to xep234 that allows multiple <file> elements in <description>”, IIRC it was the case before, and got replaced with multiple contents, not sure I remember why.

  4. Link Mauve

    “20:53:40 lovetox> there is no "end of file" signal in jingle”, IIRC this is one of the changes in my long overdue list of improvements to 0234.

  5. flow

    Link Mauve, I can find any traces of multiple <file/> elements being allowed in the history. But then again, I think the best/correct pattern would be for the sender to present the recipient a list of files via SIMS, and then let the recipient pull the ones he wants

  6. Link Mauve

    Probably yeah, or XEP-0329 or something similar.

  7. flow

    sure

  8. flow

    uh error in example in 329

  9. Link Mauve

    Where?

  10. flow

    Link Mauve, https://github.com/xsf/xeps/pull/960

  11. Link Mauve

    Thanks. :)

  12. Link Mauve

    flow, but hmm, shouldn’t @node be (correctly) reflected instead?

  13. Link Mauve

    XEP-0030 §3.2 “If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.”

  14. flow

    are those xep30 nodes?

  15. flow

    i.e. what would be returned if I disco#info them?

  16. Link Mauve

    Ah no, sorry.

  17. Link Mauve

    I confused it with XEP-0135.

  18. Link Mauve not awake enough yet.

  19. flow

    it is easy to confuse

  20. flow

    probably an argument to rename 'node' to 'path' in xep329

  21. flow

    and while it, considering switching to xep385

  22. Link Mauve

    I’m not aware of any implementation of either (nor XEP-0214).

  23. flow

    me neither

  24. Link Mauve

    During the last Operators Sprint I attempted to draft yet another one, better of course, for users to manage their 0363 files, but there were more considerations to be had than what I was ready to allocate.

  25. mathieui

    Link Mauve, re: operators sprint, did you get a reply from weblate?

  26. Link Mauve

    Nope. :(

  27. mathieui

    :/

  28. Link Mauve

    I guess we can just host it ourselves.

  29. Link Mauve

    Or use Khaganat’s or something.

  30. flow

    Link Mauve, care to update your PR comment?

  31. Link Mauve

    larma, how long did it take you to get accepted?

  32. Link Mauve

    On Weblate Hosted?

  33. Link Mauve

    flow, deleted even.

  34. flow

    thxs

  35. pep.

    flow, what should we do re 157?

  36. pep.

    Wait until registry gets fixed(tm)?

  37. pep.

    We'd still need to update some other XEP to allow for the validation bits right?

  38. flow

    I don't recall this requiring to update another XEP. It would be nice if the registry entry would be completely displayed in its html transformed version, but that is not strictly a prerequisite, as I'd argue only the raw xml entries are normative

  39. pep.

    Well judging from the list thread we can't ask for council to review the PR again right?

  40. pep.

    (baring a working registry that wouldn't have required council in the first place)

  41. flow

    well the discussion about the extensible nature of registry entries was certainly good

  42. pep.

    "what now"

  43. flow

    why can't we ask council again?

  44. flow

    (sorry, I only noticed that you wrote "can't" and not "can")

  45. flow

    I mean, we certainly can ask council again