pulkomandynav, 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
lovetoxwhy is there something loaded from other sites? i thought the xml is transformed with the xsl once and a html file is generated
Zashbrowsers can do the xslt transform
Zashe.g. if you go to the XML file https://xmpp.org/extensions/xep-0453.xml
navpulkomandy: 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.
Zashso yeah, external resources needed for the xml stylesheet is subject to CORS rules as if they were scripts
lovetoxyeah, 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
navlovetox: 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.
navlovetox: a) you don't. You only visit those which are mentioned in the DOAP file; b) you're overoptimising ☺
pulkomandylet the browser cache handle it? or put the xeps behind a CDN?
pulkomandyso, who can I ask to see if it's possible to add this header to the xeps on xmpp.org?
lovetoxof 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
pulkomandyyes that works too, the more general question is, is there a better place than here to discuss it?
navpulkomandy: 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.
navIt seems to me that wurstsalat has access to the xmpp.org repo and would be the one to ask.
navlovetox: 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.
navFor instance, I may want to host my own DOAP and apply my own stylesheet, as Gajim do.
wurstsalatnav: /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?
navIn 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.
navwurstsalat: what is the problem you're trying to solve?
wurstsalatnav, accessing 100-200 files for viewing a single doap file
wurstsalatadding the header rule wouldn't be the problem, I guess
navPut that (or similar) in the Makefile and serve the .html files.
navAssuming that you'll be hosting DOAPs in xsf/repo.
wurstsalatthey are available during build, so that wouldn't be a problem.
wurstsalatbut 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
pulkomandyyes that's the idea for using xslt
navAnyway, 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.
navTo 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.
pulkomandywell if there's a single file with all the info available I'm happy to use that instead
navpulkomandy: You can, if you're happy with not having the publication date of the implemented version of each XEP or the change history since.
navAlso, denormalisation. ☺
wurstsalatthere 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 Mauvenav, 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 MauveNot everyone got fiber, even in 2022.
navLink Mauve: why would users be accessing the .xml instead of the pre-rendered .html version?
Link MauvePlus xmpp.org is hosted in the USA, depending on where you are it adds a whole bunch of latency.
Link Mauvenav, why not?
navGood point about the traffic size from the *client's* point of view.
pulkomandyyes personally I don't plan to serve generated html when the browser can do it
pulkomandyunless the generation becomes heavy and complicated (in terms of network or computation) but then I wouldn't be using xslt to do it
Link Mauvenav, there are only three browsers left, you can probably rely on their XSLT processors.
pulkomandythey probably all use libxml
navThat's what is being currently done with XEP XMLs
Link MauveNo, Firefox uses transformiix instead.
navLink Mauve: Interesting.
pulkomandywurstsalat, 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
navBut 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.
navwurstsalat: I second pulkomandy's request. ✔
Link Mauvepulkomandy, nav, you can do it too, modify that file here: https://github.com/SamWhited/xmpp.org/blob/master/deploy/xsf.conf✎
ZashThere is another
Link Mauvepulkomandy, nav, you can do it too, modify that file here: https://github.com/xsf/xmpp.org/blob/master/deploy/xsf.conf ✏
wurstsalatThat's Sam's fork
Link Mauve(Corrected my message, sorry.)
Link Mauve(I had it loaded somewhere in my tabs.)
ZashThere are 7 layers of proxies.
wurstsalatlooking 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 MauveAlright, while we’re at it: https://github.com/xsf/xmpp.org/pull/1159
wurstsalatZash, should we have an /deploy/xsf.conf (like there is for xsf/xmpp.org) also for xsf/xeps ?
ZashNot opposed. Just be aware that there's an outer ngnix too
wurstsalatI 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
wurstsalatjonas’, what do you think? ^
navFYI, 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).
navAnyhow, I'll knock something up that uses xeplist. ☕ first though.
wurstsalatthat's impressive :)
wurstsalatnav, could be achieved with a single file, if there was a xeplist.xml with all revisions included
Dele Olajidehas left
Dele Olajidehas joined
navQ: Why does style.xsl refer to "../style.css" when style.css is in the same directory?
ZashGuess: Because they're built into a `builds/` subdirectory
ZashAlternative guess: Historical reasons lost in time.
ZashWait what are we talking about?
navZash: `sed -n 12p style.xsl`
nav <link href="../style.css" type="text/css" rel="stylesheet"/>
navCan I change that to <link href="style.css" type="text/css" rel="stylesheet"/> ?
nav(i.e., get rid of ../)
ZashI'm looking at the xeps repo and have no idea what you're talking about, sorry.
navZash: Sorry I was in my own little world. :) I'm talking about this: https://github.com/pulkomandy/xmpp-doap/blob/master/style.xsl#L12
navI'd like to change that to ./style.css to be consistent with the actual (and in deployment, likely) location of the .css file.
navAnd while at it, also add the DOCTYPE declaration to the XSLT output.
ZashWhat 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
pulkomandyso, does this look good? (using a local copy of xeplist.xml for testing): https://pulkomandy.tk/drop/xmpp-doap/samples/poezio.xml
navpulkomandy: Looks good apart from the styling of “version implemented” (smaller font than “latest version”).
ZashMaybe show a (latest $latestversion) after version implemented where relevant instead of a separate column?
pulkomandyyes, done, is it better now?
pulkomandyalso merged the XEP and Name columns
ZashHm, 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?
ZashOh, obviously this requires ... ✅️ GREEN CHECKMARKS
navZash: 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
wurstsalatWhat 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 :)
navwurstsalat: What shade of yellow? 😇
wurstsalatnav: the same as for the "partial" tag
wurstsalat(which works on both light and dark themes)
ZashThe bikeshed should be painted $(shuf -n 1 /etc/X11/rgb.txt) !
navShouldn't a committee decide that?
navlikes building bike sheds
navAnyway, the yellow box kind of thing only for outdated revisions makes sense.
wurstsalatNo, seriously, just add the "partial" class
navZash: I can add green checkmarks 🙂
navAre the abstracts guaranteed to be pure text content?
navI guess they can have mixed content also?
pulkomandyok I have green checkmarks now :)
pulkomandymaybe a further improvement is checking if at least the major version number matches, but I think it's enough xslt for today
ZashHmmm, but 0.x → 1.0 can happen without any changes
pulkomandyyes, if it's not semver it doesn't make sense to do things like that
ZashHm, isn't semver that way too?
ZashNo 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."
ZashTho here 1.0 happens when it moves forward in the process
ZashNow if only we still had the xep diff thing :(
Zash(or if I found motivation for building a new one)