XSF Discussion - 2021-01-02

Link Mauve: very cool. Good job

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?

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

Stuff it in Docker 🤷️

Yes

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

Enjoy!

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.

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)

lskdjf, indeed, that’s a good point.

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

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.

Link Mauve, maybe showing the number instead of the list

so it gives at least some information

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

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

> 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.

> 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:

> 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.

lskdjf, does it?

ah in that beta

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

Ok, 118G /var/lib/docker

I mean, sure.

Why not.

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

one heavy whale

It’s perfectly normal.

This is fine.

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

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

Link Mauve, your counting is wrong

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

otherwise you’re counting the same things multiple times

I rm -rf’d everything and started over.

(re /var/lib/docker)

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

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

Alright, my docker thingy works now.

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/

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.

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

Hmm

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

"Put that data" step sounds ambiguous and tricky

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

Maybe?

every time we update the xmpp.org thing

sounds tricky

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?

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

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

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

/ goes to the xmpp.org container

(where an nginx runs)

What it needs is /xmpp-doap/ actually.

and also the extensions/index.html?

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

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

MattJ, both!

Well, right

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

I love it /s

So the host nginx can handle specific dirs

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

right

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

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

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

I am

but not with the crude things which are done there

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

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.

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