jdev - 2022-08-08

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

why is there something loaded from other sites? i thought the xml is transformed with the xsl once and a html file is generated

browsers can do the xslt transform

e.g. if you go to the XML file https://xmpp.org/extensions/xep-0453.xml

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.

so yeah, external resources needed for the xml stylesheet is subject to CORS rules as if they were scripts

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

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.

lovetox: a) you don't. You only visit those which are mentioned in the DOAP file; b) you're overoptimising ☺

let the browser cache handle it? or put the xeps behind a CDN?

so, who can I ask to see if it's possible to add this header to the xeps on xmpp.org?

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

yes that works too, the more general question is, is there a better place than here to discuss it?

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.

It seems to me that wurstsalat has access to the xmpp.org repo and would be the one to ask.

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.

For instance, I may want to host my own DOAP and apply my own stylesheet, as Gajim do.

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?

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.

wurstsalat: what is the problem you're trying to solve?

nav, accessing 100-200 files for viewing a single doap file

adding the header rule wouldn't be the problem, I guess

wurstsalat: `saxon8 -o $DOAP.html $DOAP.xml style.xsl`

Put that (or similar) in the Makefile and serve the .html files.

Assuming that you'll be hosting DOAPs in xsf/repo.

they are available during build, so that wouldn't be a problem.

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

yes that's the idea for using xslt

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.

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.

well if there's a single file with all the info available I'm happy to use that instead

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.

Also, denormalisation. ☺

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)

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.

Not everyone got fiber, even in 2022.

Link Mauve: why would users be accessing the .xml instead of the pre-rendered .html version?

Plus xmpp.org is hosted in the USA, depending on where you are it adds a whole bunch of latency.

nav, why not?

Good point about the traffic size from the *client's* point of view.

yes personally I don't plan to serve generated html when the browser can do it

unless the generation becomes heavy and complicated (in terms of network or computation) but then I wouldn't be using xslt to do it

nav, there are only three browsers left, you can probably rely on their XSLT processors.

they probably all use libxml

That's what is being currently done with XEP XMLs

No, Firefox uses transformiix instead.

Link Mauve: Interesting.

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

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.

wurstsalat: I second pulkomandy's request. ✔

There is another

pulkomandy, nav, you can do it too, modify that file here: https://github.com/xsf/xmpp.org/blob/master/deploy/xsf.conf ✏

That's Sam's fork

but:

(Corrected my message, sorry.)

(I had it loaded somewhere in my tabs.)

There are 7 layers of proxies.

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

Alright, while we’re at it: https://github.com/xsf/xmpp.org/pull/1159

thanks!

Zash, should we have an /deploy/xsf.conf (like there is for xsf/xmpp.org) also for xsf/xeps ?

Not opposed. Just be aware that there's an outer ngnix too

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

jonas’, what do you think? ^

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

Anyhow, I'll knock something up that uses xeplist. ☕ first though.

that's impressive :)

nav, could be achieved with a single file, if there was a xeplist.xml with all revisions included

Cute!

Q: Why does style.xsl refer to "../style.css" when style.css is in the same directory?

Guess: Because they're built into a `builds/` subdirectory

Alternative guess: Historical reasons lost in time.

Wait what are we talking about?

Zash: `sed -n 12p style.xsl`

<link href="../style.css" type="text/css" rel="stylesheet"/>

Can I change that to <link href="style.css" type="text/css" rel="stylesheet"/> ?

(i.e., get rid of ../)

I'm looking at the xeps repo and have no idea what you're talking about, sorry.

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

I'd like to change that to ./style.css to be consistent with the actual (and in deployment, likely) location of the .css file.

And while at it, also add the DOCTYPE declaration to the XSLT output.

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

I.e. https://github.com/pulkomandy/xmpp-doap/commit/edcdf12c244b34e89d63f47f3788cde3d175cd2f

Hm, because the `samples/` dir?

So, not completely unlike `xeps/build/` then.

so, does this look good? (using a local copy of xeplist.xml for testing): https://pulkomandy.tk/drop/xmpp-doap/samples/poezio.xml

👍️

pulkomandy: Looks good apart from the styling of “version implemented” (smaller font than “latest version”).

Maybe show a (latest $latestversion) after version implemented where relevant instead of a separate column?

yes, done, is it better now?

also merged the XEP and Name columns

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?

Oh, obviously this requires ... ✅️ GREEN CHECKMARKS

Zash: How about either a ✅️ or a (something else) with a tooltip to the effect that there is a newer version of that XEP?

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

wurstsalat: What shade of yellow? 😇

nav: the same as for the "partial" tag

(which works on both light and dark themes)

The bikeshed should be painted $(shuf -n 1 /etc/X11/rgb.txt) !

Shouldn't a committee decide that?

Anyway, the yellow box kind of thing only for outdated revisions makes sense.

No, seriously, just add the "partial" class

Less clutter.

https://labs.navlost.eu/pub/doap/doap.html ?

Mmmmmm

Zash: I can add green checkmarks 🙂

Are the abstracts guaranteed to be pure text content?

I guess they can have mixed content also?

ok I have green checkmarks now :)

maybe a further improvement is checking if at least the major version number matches, but I think it's enough xslt for today

Hmmm, but 0.x → 1.0 can happen without any changes

yes, if it's not semver it doesn't make sense to do things like that

Hm, isn't semver that way too?

sort of

No guarantees when it's 0.x until one day you just get tired of the "0." and slap a 1.0 on it

"Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable."

Tho here 1.0 happens when it moves forward in the process

Now if only we still had the xep diff thing :(

(or if I found motivation for building a new one)

Hello `./tools/md-diff.sh xep-0363.xml xep-0363-v1.0.0 xep-0363-v1.1.0`

Oops. Forgot to send the patches

https://xmpp.labs.navlost.eu/upload/4f883a857d1fd410d36f3b5a55395c7b1d631fe5/mkLfrhTDkBbUQsKhIDJSchMICuEMWq5M9sO5THXc/0001-Add-DOCTYPE-declaration.patch

https://xmpp.labs.navlost.eu/upload/4f883a857d1fd410d36f3b5a55395c7b1d631fe5/nhIcPrJZy3Xb8kHTkHL8owSpJsBONH7wydGEmoBV/0002-Assume-that-style.css-is-in-the-same-directory-as-th.patch

https://xmpp.labs.navlost.eu/upload/4f883a857d1fd410d36f3b5a55395c7b1d631fe5/IxsflwdXkoOp8XSiqwMiD9emgFBTZeeUY95G6sQn/0003-Add-XEP-name-and-latest-available-version.patch

https://xmpp.labs.navlost.eu/upload/4f883a857d1fd410d36f3b5a55395c7b1d631fe5/7oI7ukpvWiBEUbRpKSqGkmHeKB2kma2YtOp4v5JQ/0004-Add-abstract-info.patch

I already pushed my own changes to use xeplist.xml and tweak a few other things, can you rebase tours?

pulkomandy: Oh I hadn't noticed. In theory, the abstract could have mixed content, right?

I don't kniw, but in that case putting it in the title could create some problems I guess

Because if that's the case, then title="{$xep-descriptor/abstract/text()}" is not going to work.

Exactly

OTOH, this is now coming from xeplist.xml

Which appears to convert XML elements to text and then back to XML (not quite sure why?)

So in that case, I guess it _should_ work. I'll check.

Yeah ok, the problem would actually manifest itself in ./tools/extract-metadata.py in https://github.com/xsf/xeps

This function https://github.com/xsf/xeps/blob/master/tools/extract-metadata.py#L26 looks a bit brittle

How / where is xeplist.xml used?