XSF Discussion - 2022-08-12


  1. flow

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

  2. emus

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

  3. wurstsalat

    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.

  4. wurstsalat

    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

  5. flow

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

  6. flow

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

  7. MattJ

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

  8. MattJ

    By all means bury them as inactive

  9. wurstsalat

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

  10. flow

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

  11. wurstsalat

    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

  12. flow

    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.

  13. flow

    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

  14. wurstsalat

    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

  15. wurstsalat

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

  16. flow

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

  17. wurstsalat

    yeah, that's the plan

  18. Menel

    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.

  19. wurstsalat

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

  20. Menel

    I see, thanks

  21. Zash

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

  22. emus

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

  23. emus

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

  24. emus

    compliance Badges!

  25. Guus

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

  26. emus

    😃 do you actually list supported xeps somewhere at all?

  27. flow

    we do

  28. emus

    flow: where?

  29. flow

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

  30. vanitasvitae

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

  31. singpolyma

    "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

  32. emus

    is fine but then send it to me :-)

  33. emus

    singpolyma: how else should you review compliance?

  34. singpolyma

    emus: not sure what you mean?

  35. emus

    based on the listed client xeps you can elaborate ita compliance

  36. singpolyma

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

  37. Menel

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

  38. singpolyma

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

  39. Kev

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

  40. Kev

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

  41. singpolyma

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

  42. Kev

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

  43. Kev

    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.

  44. singpolyma

    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 will yet. So do they "support" data forms or not?

  45. singpolyma

    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?

  46. emus

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

  47. MSavoritias (fae,ve)

    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

  48. emus

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