XSF Discussion - 2022-08-12

well, a lot of the same technical and social discussions/issues surface in multiple communities, like the discourse discussion ;)

Great discussion and I think the solution is great too, incl. no renewals anymore

My first proposal would be: remove all entries in {clients,servers,libraries}.json for which last_updated is "null". These entries haven't been shown anyway since 2017.

Then I'd check entries for which "last_renewed" is set, and if they don't provide a DOAP file themselves, add a bare-minimum DOAP file to host on xmpp.org

what's the advantage of removing them? it only seems to make it harder to re-add them ✏

Yeah, I'm not sure about removing them either, if links still work, etc.

By all means bury them as inactive

flow, less DOAP files to write. But yes, in the end they could be displayed in a separate "Inactive" section

if they are hidden anyways, then you don't have to write DOAP files for them, no?

flow, but I want to get rid of the "platforms" and "url" keys in the long run. this info would be lost, if not transferred to a DOAP file

hmm, I do not have immediate plans to write a DOAP for Smack but would like to keep it listed, and ideally with a URL to the project's homepage and mentioned the supported platforms.

Not because I don't like DOAPs, I find the idea appealing, but because I just don't have time, and writing DOAPs is currently a category C todo item for me

flow, that's why we want to host bare-minimum DOAP files for projects which don't provide one. That lets us simplify the processing

this includes name, shortdesc, website, os, (logo)

ahh ok, so the status-quo for smack remains the same without me having to lift a finger? I think I *could* life with that :)

yeah, that's the plan

Wherr on xmpp.org can I even see the benefits of the fancy DOAP data? From the main page I can only find https://xmpp.org/software/clients/ But that's only a name, logo and link to project.

Menel, atm, logo and short description are the only benefits. but that'll be extended soon

I see, thanks

I imagined a boring list at the bottom of the page for all the other items. Maybe hidden behind a <details>

flow: I still think your project should have a doap - cmon its smack!

> Zash wrote: > I imagined a boring list at the bottom of the page for all the other items. Maybe hidden behind a <details> *roll eyes*

compliance Badges!

> flow: I still think your project should have a doap - cmon its smack! We welcome your contribution? 😉

😃 do you actually list supported xeps somewhere at all?

we do

flow: where?

https://github.com/igniterealtime/Smack/blob/master/documentation/extensions/index.md

flow, emus: I think I have a Smack branch somewhere where I started writing a DOAP file, but that branch is probably horribly outdated.

"supported xeps" is such an interesting concept. I guess with a library it is probably more clear, but with a client it is often borderline meaningless

is fine but then send it to me :-)

singpolyma: how else should you review compliance?

emus: not sure what you mean?

based on the listed client xeps you can elaborate ita compliance

Can you though? It depends on several people's interpretation of "supporting a xep" and "compliance"

I think one can construct meaningless examples. But in reality its quite clear. Can it do http upload or not.. Etc

Menel: some are clearer that others for sure. Http upload is a great example of a pretty clear one

HTTP upload's a great example of one that's very muddy. ✏

Though even there... What does the client use http upload *for*? You can probably guess by what is common, but...

Because the XEP requires being able to set cookies on a per-request basis, which is ... not straightforward in a web client.

So people will very reasonably skip that bit. And then some day someone needs it, finds out the client that claimed to support HTTP Upload doesn't, and ... muddy.

Kev: right partial compliance is common. For example, everyone claims to support data forms just because they have a parser for it, maybe use it in ibr. But the xep allows for data forms being send in messages and tracked by thread ID... I've not found a client that supports that well yet. So do they "support" data forms or not? ✏

I know its not perfect but I believe its the best step in the right direction.

I agree we need some ways to show it to whoever ends up on the page. People still install pidgin because they are not "in the know" for example

One thing I try to improve in general in XMPP is central communication, thats why I support this.