nav, thanks for the patch to xmpp-doap, it looks like it should work, but when rendering the xml in a browser, it doesn't work because of cross site resource loading. I don't know enough about web dev to see if this could be fixed by allowing it, from one side or the other
norayrhas left
norayrhas joined
lovetox
why is there something loaded from other sites? i thought the xml is transformed with the xsl once and a html file is generated
Zash
browsers can do the xslt transform
Zash
e.g. if you go to the XML file https://xmpp.org/extensions/xep-0453.xml
nav
pulkomandy: Hi, no bother. For the XML to render in the browser what it's needed is to send `Access-Control-Allow-Origin: *` CORS headers with the `https://xmpp.org/extensions/*.xml` files.
Zash
so yeah, external resources needed for the xml stylesheet is subject to CORS rules as if they were scripts
spiralhas left
spiralhas joined
lovetox
yeah, but there are 400 xeps, how is that implemented right now? we cannot query 400 xml files everytime someone looks at the page what our client supports
nav
lovetox: you can do it either way: generate an .html from the .xml during the site's build stage (via the Makefile) and/or have the browser do it. The XEPs on xmpp.org currently do both as Zash says.
nav
lovetox: a) you don't. You only visit those which are mentioned in the DOAP file; b) you're overoptimising ☺
pulkomandy
let the browser cache handle it? or put the xeps behind a CDN?
pulkomandy
so, who can I ask to see if it's possible to add this header to the xeps on xmpp.org?
lovetox
of course we add now more infrastructure to xmpp.org so people can look at doaps ... oooor maybe we get the information we need from a single xml file instead of hundreds
pulkomandy
yes that works too, the more general question is, is there a better place than here to discuss it?
nav
pulkomandy: What are the traffic figures on xmpp.org? I have difficulty believing that a few hundred / thousand extra requests a day would be a problem. Anyway, if it were up to me I would generate the .htmls in the Makefile *and* add the CORS header so that visiting the XML directly also works, if nothing else to be consistent with the XEPs.
nav
It seems to me that wurstsalat has access to the xmpp.org repo and would be the one to ask.
debaclehas joined
xnamedhas left
nav
lovetox: You could, and collecting DOAPs and adding them to the relevant sections of https://xmpp.org/software/ would probably not be a bad idea. However, I'd still set the CORS headers.
nav
For instance, I may want to host my own DOAP and apply my own stylesheet, as Gajim do.
wurstsalat
nav: /extensions/xep-xxxx is populated by the xsf/xeps repo. There is xeplist.xml, which holds the name already. Maybe it's time to upgrade that file or add another xeplist-revision-history.xml for your needs?
nav
In that case, if I can just put the XML somewhere accessible to the public and don't have to bother with a build step, which I almost certainly wouldn't anyway.
nav
wurstsalat: what is the problem you're trying to solve?
wurstsalat
nav, accessing 100-200 files for viewing a single doap file
wurstsalat
adding the header rule wouldn't be the problem, I guess
Put that (or similar) in the Makefile and serve the .html files.
nav
Assuming that you'll be hosting DOAPs in xsf/repo.
nikhas left
xeckshas left
wurstsalat
they are available during build, so that wouldn't be a problem.
wurstsalat
but it would require every project which wants to display their doap file to make/render it. for me, it was appealing that this simply isn't necessary, because browsers do the rendering themselves
pulkomandy
yes that's the idea for using xslt
nav
Anyway, I don't know what the traffic stats are for xmpp.org, but I very much doubt that accessing the entire XEP collection on DOAP styled views would be a problem at all. It's only a few hundred fairly small files, so they'll probably end up in the disk / nginx cache anyway and not generate any significant extra load, assuming that the site does not get millions of hits per hour.
nav
To be clear, I would still generate .html at build time, but only because it's easy to do and secondarily because you don't have to depend on the vagaries of XSLT implementation on every different browser out there.
xeckshas joined
pulkomandy
well if there's a single file with all the info available I'm happy to use that instead
nav
pulkomandy: You can, if you're happy with not having the publication date of the implemented version of each XEP or the change history since.
nav
Also, denormalisation. ☺
wurstsalat
there is https://xmpp.org/extensions/xeplist.xml (but nav wants to display the date of the implemented revision, which is not available in that file)
Link Mauve
nav, the issue isn’t about xmpp.org, but about users who suddenly have to do so many requests to somewhat big files when a single one would be enough.
Link Mauve
Not everyone got fiber, even in 2022.
nav
Link Mauve: why would users be accessing the .xml instead of the pre-rendered .html version?
Link Mauve
Plus xmpp.org is hosted in the USA, depending on where you are it adds a whole bunch of latency.
Link Mauve
nav, why not?
nav
Good point about the traffic size from the *client's* point of view.
pulkomandy
yes personally I don't plan to serve generated html when the browser can do it
pulkomandy
unless the generation becomes heavy and complicated (in terms of network or computation) but then I wouldn't be using xslt to do it
Link Mauve
nav, there are only three browsers left, you can probably rely on their XSLT processors.
raghavgururajanhas left
pulkomandy
they probably all use libxml
nav
That's what is being currently done with XEP XMLs
Link Mauve
No, Firefox uses transformiix instead.
nav
Link Mauve: Interesting.
pulkomandy
wurstsalat, ok, so can we get xmpp.org to allow cross source access on xeplist.xml? meanwhile I can download a local copy to experiment and update the xslt to use it
nav
But yes, if you'll be serving primarily (or only) the .xml version then yes, I see how hitting a single other file would be better from the client's point of view.
atomicwatchhas joined
stpeterhas joined
nav
wurstsalat: I second pulkomandy's request. ✔
Link Mauve
pulkomandy, nav, you can do it too, modify that file here: https://github.com/SamWhited/xmpp.org/blob/master/deploy/xsf.conf✎
xnamedhas joined
Zash
There is another
Link Mauve
pulkomandy, nav, you can do it too, modify that file here: https://github.com/xsf/xmpp.org/blob/master/deploy/xsf.conf ✏
wurstsalat
That's Sam's fork
wurstsalat
but:
Link Mauve
(Corrected my message, sorry.)
Link Mauve
(I had it loaded somewhere in my tabs.)
Zash
There are 7 layers of proxies.
wurstsalat
looking at the infra, maybe it would be wise to do nginx rules per repo, as I see "xeps" also sets some nginx rule here: https://github.com/xsf/xeps/blob/master/Dockerfile#L22
Link Mauve
Alright, while we’re at it: https://github.com/xsf/xmpp.org/pull/1159
wurstsalat
thanks!
selurveduhas joined
norayrhas left
norayrhas joined
wurstsalat
Zash, should we have an /deploy/xsf.conf (like there is for xsf/xmpp.org) also for xsf/xeps ?
Zash
Not opposed. Just be aware that there's an outer ngnix too
wurstsalat
I don't have further insights here, but I'd like to avoid setting nginx rules via the xmpp.org repo to /extensions/xeplist.xml, which is fed by xsf/xeps
wurstsalat
jonas’, what do you think? ^
nav
FYI, this is why I think being able to access the xep*.xml is a good idea: https://labs.navlost.eu/pub/doap.html (the question marks open a pop-up with the list of missing changes). With that say, I'm not advocating putting that much info in something intended for users. On the other hand, as an implementor, I find it handy to see at a glance what I am missing and if I need to bring my implementation up to date (e.g., if it's just an editorial change or something significant).
nav
Anyhow, I'll knock something up that uses xeplist. ☕ first though.
wurstsalat
that's impressive :)
wurstsalat
nav, could be achieved with a single file, if there was a xeplist.xml with all revisions included
Link Mauve
Cute!
Dele Olajidehas left
Dele Olajidehas joined
nav
Q: Why does style.xsl refer to "../style.css" when style.css is in the same directory?
rubihas left
Zash
Guess: Because they're built into a `builds/` subdirectory
Zash
Alternative guess: Historical reasons lost in time.
Can I change that to <link href="style.css" type="text/css" rel="stylesheet"/> ?
spiralhas joined
nav
(i.e., get rid of ../)
Zash
I'm looking at the xeps repo and have no idea what you're talking about, sorry.
nav
Zash: Sorry I was in my own little world. :) I'm talking about this: https://github.com/pulkomandy/xmpp-doap/blob/master/style.xsl#L12
nav
I'd like to change that to ./style.css to be consistent with the actual (and in deployment, likely) location of the .css file.
nav
And while at it, also add the DOCTYPE declaration to the XSLT output.
Zash
What I would do: Check the history of that line, see there are any reasons for it to be that way mentioned when it was added, or if it made sense at the time but not now etc
Zash
I.e. https://github.com/pulkomandy/xmpp-doap/commit/edcdf12c244b34e89d63f47f3788cde3d175cd2f
Zash
Hm, because the `samples/` dir?
Zash
So, not completely unlike `xeps/build/` then.
jubalhhas left
pulkomandy
so, does this look good? (using a local copy of xeplist.xml for testing): https://pulkomandy.tk/drop/xmpp-doap/samples/poezio.xml
jubalhhas joined
miruxhas left
miruxhas joined
Zash
👍️
nav
pulkomandy: Looks good apart from the styling of “version implemented” (smaller font than “latest version”).
Zash
Maybe show a (latest $latestversion) after version implemented where relevant instead of a separate column?
selurveduhas left
lovetox2has joined
lovetox2has left
lovetox2has joined
lovetox2has left
heartyhas joined
colemanhas left
pulkomandy
yes, done, is it better now?
pulkomandy
also merged the XEP and Name columns
Zash
Hm, I was thinking that the latest version is a bit redundant when it is equal to the implemented one, so one could hide it or just show (latest) maybe?
rubihas joined
Zash
Oh, obviously this requires ... ✅️ GREEN CHECKMARKS
jubalhhas left
antranigvhas left
antranigvhas joined
nav
Zash: How about either a ✅️ or a (something else) with a tooltip to the effect that there is a newer version of that XEP?
Dele Olajidehas left
wurstsalat
What I had in mind was a yellow box with an exclamation mark for only those which are not up to date (less clutter). But that's bike shedding, and I'd implement that myself later, if needed :)
nav
wurstsalat: What shade of yellow? 😇
wurstsalat
nav: the same as for the "partial" tag
wurstsalat
(which works on both light and dark themes)
Zash
The bikeshed should be painted $(shuf -n 1 /etc/X11/rgb.txt) !
nav
Shouldn't a committee decide that?
navlikes building bike sheds
nav
Anyway, the yellow box kind of thing only for outdated revisions makes sense.
wurstsalat
No, seriously, just add the "partial" class
nav
Less clutter.
alhas joined
norayrhas left
norayrhas joined
nav
https://labs.navlost.eu/pub/doap/doap.html ?
Zash
Mmmmmm
nav
Zash: I can add green checkmarks 🙂
stpeterhas left
nav
Are the abstracts guaranteed to be pure text content?
nav
I guess they can have mixed content also?
pulkomandy
ok I have green checkmarks now :)
antranigvhas left
stpeterhas joined
antranigvhas joined
thomaslewishas joined
pulkomandy
maybe a further improvement is checking if at least the major version number matches, but I think it's enough xslt for today
thomaslewishas left
techmetx11has left
Zash
Hmmm, but 0.x → 1.0 can happen without any changes
thomaslewishas joined
techmetx11has joined
pulkomandy
yes, if it's not semver it doesn't make sense to do things like that
Zash
Hm, isn't semver that way too?
pulkomandy
sort of
Zash
No guarantees when it's 0.x until one day you just get tired of the "0." and slap a 1.0 on it
pulkomandy
"Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable."
alhas left
Zash
Tho here 1.0 happens when it moves forward in the process