XSF Discussion - 2019-02-11


  1. zinid

    jonas’, http upload (XEP-0363) has LC ended, but it's not reflected in the document

  2. zinid

    jonas’, is it a known issue?

  3. jonas’

    zinid, yes

  4. jonas’

    kind ofg

  5. zinid

    ofg?

  6. jonas’

    kind of

  7. jonas’

    I had no weekend and am back at work, don’t have the energy to look into this now

  8. zinid

    sure, just checking the condition of our xeps :D

  9. jonas’

    I think there is a vote on the LC result pending for council, but I’m not sure

  10. Guus

    dwd ^ do you know?

  11. dwd

    HTTP upload... I can't recall the current status, but its last call brought up some security issues. I think those have been addressed, but I can't remember if we've done anything since.

  12. edhelas

    I'd like to enforce Pubsub nodes to return their access model in their metadata, goffi what do you think ?

  13. edhelas

    if not it's impossible for a client to know what to do/display when requesting a node

  14. edhelas

    access_model and publish_model

  15. edhelas

    it's a small change for 0060 but it will greatly help for the clients to display properly things in their UI

  16. pep.

    PR against 0060, see what council says :)

  17. edhelas

    will do

  18. Kev

    While I'm happy for you to work that way if you want, it's a somewhat expensive way of saying "What do you think of the idea?".

  19. Ge0rG

    the standard way for ""What do you think of the idea?" is to post to standards@ and not receive any responses, right?

  20. Zash

    Correct

  21. edhelas

    :)

  22. Zash

    No responses, no objections!

  23. Ge0rG

    Zash: speaking of which. How's the GC1.0 removal going?

  24. Zash

    Ge0rG: From spec or code?

  25. Ge0rG

    Zash: from spec

  26. Zash

    Ge0rG: I did the same thing you did, realized that it was a larger task than initially expected and gave up half-way

  27. Ge0rG

    Zash: we should have bundled our efforts

  28. Ge0rG

    OTOH, it is good to be independently confirmed in my conclusion

  29. Zash

    We could have given up twice as fast!

  30. Guus

    I like how we're optimizing failure here!

  31. Seve

    I prefer to discuss a bit before making a PR, so you know more or less if you are on the right path

  32. Ge0rG

    Regarding GC1.0, there was a discussion on standards@, and some Council member proclaimed that they wouldn't oppose removing it if it doesn't make things worse.

  33. pep.

    Seve: the issue is that you often don't get an answer :p

  34. Ge0rG

    However, this is a very subjective matter. I've come to the conclusion that a MUC treating a presence update as a join and flooding me with message duplicates is worse than being dropped off properly.

  35. Seve

    Sad

  36. Zash

    Seve: Probably because most people don't bother replying with "Meh" or "Sounds fine but I don't really care about this that much"

  37. flow

    Ge0rG, Zash: If there where a git with the current state of your GC1 removal, people could and probably would collaborate and help (at least I would had a look too)

  38. Ge0rG

    flow: that's exactly the problem. We both started at the paragraph first mentioning GC1.0, tried to remove it and realized that it needs to be written from scratch.

  39. Ge0rG

    If somebody had started removing the protocol pieces instead, things might move forward faster

  40. flow

    I am not sure how that problem keeps you from creating a git where people could collaborate?

  41. flow

    I would even offer my repo, which would automatically create HTML diffs to the current xep45 version

  42. flow

    (assuming the html diff tool is able to deal with xep45-sized xeps)

  43. Ge0rG

    flow [10:50]: > which would automatically create HTML diffs to the current xep45 version Can we have that functionality please? Not as SaaS, but for use everywhere and anywhere?

  44. Ge0rG

    flow, Zash: https://github.com/ge0rg/xeps/commit/11bf5c82fba0f46eb6e5560213d508fea4941396 (branch xep0045-kill-gc1)

  45. Zash

    Ah right, this problem > Compliant multi-user chat services MUST accept [Groupchat 1.0]

  46. Ge0rG

    Zash: prosody 0.11 is incompliant!

  47. flow

    IIRC there was consensus that it's ok. And while I am a strong supporter of namespace bumps on incompatible changes, I'd also simply remove GC1 without an bump

  48. Zash

    flow, Ge0rG: https://github.com/ge0rg/xeps/compare/xep0045-kill-gc1...Zash:xep0045-kill-gc1?expand=1

  49. Zash

    excuse the whitespace

  50. ralphm

    Zash: you probably should also around some more, because now the first thing you see in the section is the error response.

  51. ralphm

    should *move* around

  52. Zash

    Didn't I move that?

  53. Zash

    I'm sure I moved that up

  54. Zash runs `git diff`

  55. Zash

    ah, of course, that's not committed

  56. Zash

    thanks git

  57. ralphm

    (and ralphm)

  58. Zash

    ralphm: thanks

  59. Zash

    updated the thing

  60. ralphm

    Kind wondering: should the id attribute of the error stanza match the original?

  61. ralphm

    Kinda

  62. ralphm

    Oh, never mind, the error response doesn't have an example of the original stanza.

  63. flow

    Ge0rG, Zash: http://geekplace.eu/xeps/xep-muc-no-gc1/diff-side-by-side.html

  64. Guus

    That's a convenient tool! It'd be handy if it had a 'go to next change' action.

  65. pep.

    oh wow that's cool

  66. Seve

    very nicey

  67. pep.

    (Also scrolling down MUC takes some time..)

  68. edhelas

    that's nice yes, could be nice to navigate directly to the changes

  69. goffi

    edhelas: I think enforcing would need a namespace bump which is not really possible seing the current "draft" status of XEP-0060, but with a SHOULD instead of a MUST it would be a nice addition. Probably trying to do a PR and see what council say is a good way to move forward.

  70. Ge0rG

    flow: that's awesome, at least on a 1920x1080 display :)

  71. flow

    now even with colored xml diff for the brave: http://geekplace.eu/xeps/xep-muc-no-gc1/xml-colordiff.html

  72. jonas’

    flow, http://geekplace.eu/xeps/xep-muc-no-gc1/diff-side-by-side.html can you make it so that it uses the full screen width?

  73. jonas’

    it’s annoying to read even on a large display

  74. flow

    jonas’, I can do whatever https://github.com/cygri/htmldiff can do

  75. jonas’

    I don’t know what htmldiff can do

  76. jonas’

    you probably know that better than I do, given that you’ve set it up

  77. flow

    The point is that I only use a python tool to generate the diff, and I don't know what the tool can do besides producing the output shown. From a quick look, the answer is probably "no"

  78. Ge0rG

    That color diff HTML shows as xml in my browser.

  79. jonas’

    Ge0rG, because it’s a color diff of the XML

  80. Ge0rG

    I was lured by the .html file ending.

  81. MattJ

    Yeah, don't view source on that :)

  82. Ge0rG

    I just tapped the link 🤷

  83. flow

    that is why I wrote "for the brave" :)

  84. flow

    awaiting your GC1 removal PRs in case you want to collaborate on that

  85. pep.

    I really wish I could see diffs of the changes, instead of reading the revision history in the XEP and wondering what happened

  86. pep.

    In the end I'm reading the git version in the xeps repo anyway

  87. Ge0rG

    pep.: yeah, a rendered diff version, even side-by-side, is a huge help for reviewing PRs

  88. pep.

    Ge0rG, I meant in the XEPs themselves

  89. Ge0rG

    pep.: we used to have that

  90. pep.

    https://xmpp.org/extensions/xep-0045.html#appendix-revs this is useless to me

  91. Ge0rG

    before The Big Crash

  92. pep.

    I see

  93. Ge0rG

    We had a renderer that produced an inline-diff based on two revisions of a given XEP

  94. Ge0rG

    It used to be like this: http://xmpp.org/extensions/diff/api/xep/0325/diff/0.2/vs/0.3

  95. Ge0rG

    flow: how many hours of CPU time does htmldiff consume for 0045?

  96. Ge0rG

    Ah! > htmldiff build/xep-0045.master.html build/xep-0045.html > xep-0045.diff.html > 393.65s user 0.12s system 99% cpu 6:33.83 total

  97. moparisthebest

    fast, efficient

  98. moparisthebest

    just like you'd expect from python

  99. Zash

    Ge0rG: And you haven't borrowed Link Mauves toaster?

  100. Ge0rG

    model name : Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz

  101. zinid

    hardware is cheap nowadays I'm told, just upgrade

  102. Ge0rG

    It's running on a single core. You can't get cores an order of magnitude faster than that.

  103. Ge0rG

    And even then it'd still be slow.

  104. zinid

    do you mean to say that I cannot just by more CPU? o_O That's strange :/

  105. zinid

    *buy

  106. zinid

    I'm also told that Python's GIL is not a problem at all

  107. zinid

    python taliban is funny

  108. moparisthebest

    just wait for Link Mauve to rewrite it in Rust :D

  109. Zash

    WLMRIIR is the new RIIR

  110. moparisthebest

    it's better because then *we* don't have to do any work

  111. Ge0rG

    But it will be full of race conditions!

  112. zinid

    just lock everything

  113. Zash

    Launch 200 instances of the process and accept bets on which will finish first

  114. Ge0rG

    Launch one on each paragraph.

  115. Zash

    https://cerdale.zash.se/upload/eW2Xm7GsFtjj6AGW/killgc10.html

  116. Zash

    Not as pretty, but took 2s

  117. moparisthebest

    speak of the devil look what someone just sent me :) https://github.com/konchunas/pyrs "Python to Rust transpiler"