XSF Discussion - 2021-01-02


  1. Daniel

    Link Mauve: very cool. Good job

  2. Link Mauve

    Hi, with the XSF infra, what would be the best way to run a script approximately once a day, with persistent cache and persistent artefacts exposed to the web?

  3. Link Mauve

    My current poc is a web app, but it could perfectly generate static files anyway.

  4. Zash

    Stuff it in Docker 🤷️

  5. MattJ

    Yes

  6. Link Mauve

    I have never done anything with Docker, but I’ll try to do that. :)

  7. MattJ

    Enjoy!

  8. lskdjf

    Link Mauve, nice work with the client/lib info alongside the xeps 🙂 One remark: I think it's not a great idea to try and squeeze all (or any, really) supporting client/server/lib logos into the XEP overview. For popular XEPs there are lots of supporting clients and servers (more than are currently included), and displaying each logo in the XEP-row requires a considerable amount of space. I'd suggest to either only display the supporting clients/servers/lib on the XEP page or at least to make it possible to show/hide them on the overview page and to hide them by default.

  9. mathieui

    yes, I think it would make sense to have it available but not displayed by default in the index (imo individual XEPs are fine though)

  10. Link Mauve

    lskdjf, indeed, that’s a good point.

  11. Link Mauve

    How would you do that, only pick a (random?) subset?

  12. lskdjf

    maybe I should clarify the brackets in my last sentence 😀 The hiding/not displaying was only about the overview page. Showing them in the XEP page is fine.

  13. mathieui

    Link Mauve, maybe showing the number instead of the list

  14. mathieui

    so it gives at least some information

  15. mathieui

    (I’m not an UX designer so don’t take my word too seriously though)

  16. Link Mauve

    I think I have something which looks like a working docker thingy now.

  17. lskdjf

    > How would you do that, only pick a (random?) subset? I don't think a random subset would be very helpful, as it doesn't really inform you about the popular xeps anymore (which is the main usecase of displaying it all, I guess?). I think hiding the full set of client/server logos from the overview by default would be a good idea. As an alternative I also like mathieui's suggestion of displaying the total number of implementations instead of individual logos, as it provides a sufficiently good (and short) overview.

  18. emus

    > lskdjf wrote: > Link Mauve, nice work with the client/lib info alongside the xeps 🙂 One remark: I think it's not a great idea to try and squeeze all (or any, really) supporting client/server/lib logos into the XEP overview. For popular XEPs there are lots of supporting clients and servers (more than are currently included), and displaying each logo in the XEP-row requires a considerable amount of space. I'd suggest to either only display the supporting clients/servers/lib on the XEP page or at least to make it possible to show/hide them on the overview page and to hide them by default. Maybe the client column could just link to a subpage with all clients supporting that XEP. Or a by default collapsed view Link Mauve:

  19. lskdjf

    > Maybe the client column could just link to a subpage with all clients supporting that XEP. the XEP page contains a table with all supporting clients already. I don't think it needs yet another page for that.

  20. jonas’

    lskdjf, does it?

  21. jonas’

    ah in that beta

  22. lskdjf

    jonas’, in Link Mauve's version, yes: https://linkmauve.fr/extensions/xep-0054.html

  23. Link Mauve

    Ok, 118G /var/lib/docker

  24. Link Mauve

    I mean, sure.

  25. Link Mauve

    Why not.

  26. Link Mauve

    I’ve played with it for a total of like one hour after all.

  27. wurstsalat

    one heavy whale

  28. Link Mauve

    It’s perfectly normal.

  29. Link Mauve

    This is fine.

  30. mathieui

    good thing you didn’t play with it using your toaster

  31. jonas’

    I don’t like

  32. jonas’

    I don’t like that particular rendering, but the idea is neat

  33. jonas’

    Link Mauve, your counting is wrong

  34. jonas’

    there are a lot of mounted things, you need to run du with -x

  35. jonas’

    otherwise you’re counting the same things multiple times

  36. Link Mauve

    I rm -rf’d everything and started over.

  37. jonas’

    (re /var/lib/docker)

  38. Link Mauve

    I now have fiber, so I can waste that stuff. :p

  39. Link Mauve

    I now have fiber, so I can waste that bandwidth. :p

  40. Link Mauve

    I now have fiber, so I can afford to waste that bandwidth. :p

  41. Link Mauve

    Alright, my docker thingy works now.

  42. Link Mauve

    MattJ, Zash, feel free to clone https://git.linkmauve.fr/xmpp-doap.git, docker build xmpp-doap, and docker run -v ~/dev/web/xmpp.org:/xmpp.org -v ~/output/xmpp-doap:/data it. o/

  43. Link Mauve

    You’ll end up with the data in ~/output/xmpp-doap, put that directory at the root of https://xmpp.org and it will be ready.

  44. MattJ

    flow: smack is notably missing from

  45. MattJ

    flow: smack is notably missing from https://xmpp.org/software/libraries.html

  46. MattJ

    Hmm

  47. jonas’

    Link Mauve, the root of xmpp.org lives in a docker container, not in a volume or somesuch

  48. MattJ

    "Put that data" step sounds ambiguous and tricky

  49. jonas’

    hm, so we’ll have to do a docker cp I think?

  50. Link Mauve

    Maybe?

  51. jonas’

    every time we update the xmpp.org thing

  52. jonas’

    sounds tricky

  53. jonas’

    maybe this should rather be a script inside the xmpp.org container which gets called by the entrypoint and which we can call as a cronjob from the host machine?

  54. Link Mauve

    I know nothing about docker, I just did one which generates the tree of files to be used.

  55. Link Mauve

    Couldn’t you also point the web server to that particular directory?

  56. MattJ

    That could work if it wasn't in the xmpp.org root

  57. MattJ

    / goes to the xmpp.org container

  58. jonas’

    (where an nginx runs)

  59. Link Mauve

    What it needs is /xmpp-doap/ actually.

  60. jonas’

    and also the extensions/index.html?

  61. Link Mauve

    No, that’s /xmpp-doap/extensions.json

  62. MattJ

    jonas’: is nginx not outside the container? Or was that a different server?

  63. jonas’

    MattJ, both!

  64. MattJ

    Well, right

  65. jonas’

    there is an nginx on the host, and each web site part comes with its own nginx

  66. jonas’

    I love it /s

  67. MattJ

    So the host nginx can handle specific dirs

  68. jonas’

    Link Mauve, oh, so this requires JS to work?

  69. jonas’

    right

  70. Link Mauve

    jonas’, yes, I wanted to avoid to modify Pelican.

  71. Link Mauve

    It could be integrated possibly, but so far I’ve been unable to get it to build. ^^'

  72. Zash

    Is anyone on the website or iteam really familiar with Pelican?

  73. jonas’

    I am

  74. jonas’

    but not with the crude things which are done there

  75. jonas’

    the xmpp.org website is way beyond what pelican can easily do and it’s a crude hack

  76. Zash

    I think it would help the newsletter team a lot if they could preview the site easily, but that takes some major effort in my experience.

  77. emus

    Yes, it indeed would, but I only can do some python and lag any http or CSS stuff entirely 😬️