XSF Discussion - 2017-09-29


  1. jonasw

    moparisthebest, there’s always git commit --allow-empty

  2. jonasw

    Guus, merge the new favicon? :)

  3. Guus

    jonasw: wilco

  4. Guus

    was giving others some time to react

  5. jonasw

    \o/

  6. jonasw

    hm, firefox doesn’t show a favicon anymore

  7. jonasw

    ah, now it does

  8. edhelas

    you can see the difference on the favicon ? :D

  9. jonasw

    sure

  10. jonasw

    my tabs have dark background

  11. jonasw

    the new favicon has transparent background

  12. jonasw

    instead of white

  13. edhelas

    :)

  14. mathieui

    indeed

  15. Guus

    Yeah, the missing white square is quite visible

  16. Guus

    (as is the alignment change)

  17. Guus

    Supposedly, this now looks good if you drag/drop the address as a tile in your favorite brand of touchscreen device.

  18. Guus

    (but I didn't check for that)

  19. Zash

    I get 404 on https://xmpp.org/favicon-16x16.png and https://xmpp.org/favicon-32x32.png

  20. Zash

    but https://xmpp.org/favicon.ico seems to exist

  21. Guus

    ah, those are likely missing redirects

  22. Guus

    we keep those in https://xmpp.org/icons/favicon-16x16.png etc

  23. Guus

    (unsure why)

  24. Guus

    that's odd. It appears to be a pelican-based redirect?

  25. Guus

    Simply fixing the template to have the correct paths seems more sensible to me.

  26. Guus

    https://github.com/xsf/xmpp.org/pull/371 should fix it

  27. Guus

    anyone want to have a quick look?

  28. Guus

    hmmm, I might've jumped the gun there

  29. jonasw

    I don’t think that’ll work with pelican

  30. jonasw

    you need to declare static directories

  31. jonasw

    and declaring content as static won’t work/blow up everything

  32. jonasw

    now all we need to do is to find out why the XEP list is incomplete

  33. Guus

    jonasw: Yeah, i found that myself. I've revoked that PR, and created (and merged) another

  34. Guus

    I'll need to leave in 25 minutes, with many things to do until then.

  35. Guus

    I'm afraid you're on your own for the XEP list for today

  36. jonasw

    I see

  37. jonasw

    meh, I was hoping it would magically work

  38. jonasw

    that XEP list still frightens me

  39. Guus

    I can imagine

  40. jonasw

    I do not understand how that is run in docker at all. the docker build never invokes buildCompleteWebsite.sh

  41. Guus

    jonasw: I'm finding that the extensions root points to a temp dir

  42. Guus

    where the initial crash recovery took place

  43. Guus

    want me to remove that real quick?

  44. jonasw

    dooont

  45. jonasw

    I bet that file isn’t built

  46. jonasw

    that’d explain what I’m (not) seeing in the xmpp.org repository

  47. jonasw

    the built script is not invoked at all, if you remove that we won’t have any list

  48. jonasw

    the build script is not invoked at all, if you remove that we won’t have any list

  49. jonasw

    (now at least it makes sense that I don’t find the invocation of the build script, thanks for taking a look)

  50. jonasw

    I’ll then figure out a cheap way to generate the XEP table with the docker things

  51. Guus

    ok. it's line 83-85 in the xmpp.org nginx config file on eos. Any iteamer should be able to help you

  52. jonasw

    thanks

  53. Guus

    I'll be offline during the weekend

  54. jonasw

    okay

  55. jonasw

    have fun

  56. Guus

    well, on mobile

  57. Guus

    tx

  58. Flow

    Tobias: ping about https://github.com/xsf/xeps/pull/508#issuecomment-331070510

  59. Flow

    Ge0rG: How is "Battery saving (CSI) and push have different rules again" a problem?

  60. Ge0rG

    Flow: it's a matter of consistency

  61. Ge0rG

    Flow: also, nobody quite knows which rules to apply for push and csi

  62. Flow

    What would be better if they had consisten rules? Besides CSI deliberately specifies no strict rules at all (which is a good thing IMHO)

  63. MattJ

    Glad someone agrees with me :)

  64. Flow

    I mean it's not an easy thing to answer. It's one of the fields where experience from running code really matters

  65. Flow

    And something we eventually don't have to solve together with all the other more important and relevant issues you mention

  66. dwd

    Agreed. It's also not an easy thing to specify, and unclear what the interop failure by not doing so might be.

  67. dwd

    ie, it's a QoI issue. Some servers might be "better" (or at least more suitable for the client application), but everything should work one way or another eventually.

  68. Ge0rG

    Flow: https://prosody.im/issues/issue/973 and check mod_csi_battery_saver source code for the many exceptions

  69. Flow

    Ge0rG: I fully aggree that it's important that we research working rules for CSI and Push. I just wanted to say that I don't think that those rules are necessarly the same, and that it's not an issue we should focus on right now

  70. MattJ

    Ge0rG, a couple of notes on that: it's still experimental code, and that report from you is good and healthy so we can improve the rules

  71. Ge0rG

    Flow: I never claimed I have the solutions

  72. MattJ

    The alternative would have been encoding all these rules into the XEP without prior experience

  73. Flow

    Ge0rG: I would never insinuate you to have solutions ;)

  74. MattJ

    and once encoded, never being able to iterate on them and innovate

  75. Flow

    I do wonder if Session 2.0 and Bind2/SASL2 are two distinct steps into the right direction

  76. Flow

    (but maybe I should read the slides to the end)

  77. Ge0rG

    Flow: I'm pretty sure that CSI and push have the same underlying principles

  78. Flow

    Maybe, maybe not

  79. Flow

    Hrm, Message Routing 2.0 sounds a lot like XMPP 2.0

  80. Ge0rG

    Flow: we decided to rename XMPP 2 into MR 2 to show it's not a complete reinvention of everything

  81. Flow

    Probably a good idea

  82. Ge0rG

    dwd: "everything should work one way or another eventually." is something I'd rather like to avoid, because then we'll end up with even more hairy corner cases.

  83. Flow

    Ge0rG: What happens in MR 2.0 with messages send to a full JID which is unavailable?

  84. Flow

    And is MR 2.0 also signled on s2s links?

  85. Flow

    *signaled

  86. Ge0rG

    Flow: MR2 should be also signalled on s2s, yeah. And messages are errored back

  87. Ge0rG

    s2s MR2 will just follow the same semantics, and convert to MR1 clients

  88. dwd

    Ge0rG, CSI explicitly is not allowed to change the semantics of the stream, only introduce delay.

  89. Ge0rG

    dwd: I'm not sure what you are talking of

  90. Flow

    dwd: BTW I've published a new version of compare-and-publish and send a mail to standards@, not sure if you saw it yet. As always, your feedback is appreciated.

  91. Ge0rG

    MattJ: I'm okay with the rules being worded as MAY everywhere, as long as they are comprehensive according to current state of the art, and not the mess we have in 0280 now

  92. Flow

    I don't think the CSI and Carbons situation is comparable

  93. Ge0rG

    Flow: I'm talking about bad wording.

  94. Ge0rG

    Flow: and yeah, session2 and bind2 are distinct steps