XSF Discussion - 2022-11-10

  1. emus

    Kind reminder: Tue, 6th of December XMPP Open End of the year talk 7pm, CEST Please announce your topics to present and discuss, even though we are open for a general MeetUp mentalitiy. Some small announced starters and the open fade out would be great. Cheers

  2. emus

    I will likely summarize a bit of my work

  3. jonas’

    emus, what's the venue?

  4. emus

    Via jitsi I believe. I will announce more officially later

  5. jonas’

    which jitsi? :-)

  6. emus

    :D I am happy you cannot await the event! 😅 I will send a mail later - deal? :-)

  7. jonas’

    just wanting to make sure that this is a resolved question :-).

  8. emus

    Thabks, I suggets after my mail we can restart the discussion if required

  9. emus

    Thanks, I suggets after my mail we can restart the discussion if required

  10. edhelas


  11. mjk

    so Poezio has an antagonist :)

  12. mjk

    ...and Roezio a friend

  13. mdosch

    > Note that as the state of XMPP in Rust is still pretty immature, we could not find any sufficiently-advanced pure-Rust XMPP client library. Therefore, we opted for the excellent C-based libstrophe library. However, depending on a non-Rust binding creates a lot of overhead for the developer, thus we plan to create a pure-Rust port of libstrophe in the near future. We aim for a similar API to libstrophe, as we like its simplicity for the developer and how lightweight it is. Isn't there someone here working on a rust lib?

  14. wurstsalat

    https://gitlab.com/xmpp-rs/xmpp-rs this?

  15. mdosch

    Probably. Reasing 'WIP' it's probably one they consider immature.

  16. mdosch

    Probably. Reading 'WIP' it's probably one they consider immature.

  17. mjk

    so instead of contributing, they took libstrophe and rrir 😮‍💨️

  18. mjk

    so instead of contributing, they took libstrophe and riir 😮‍💨️

  19. wurstsalat

    there seems to be support for many things already: https://xmpp.org/software/libraries/xmpp-rs/ [Show supported XEPs]

  20. mdosch

    > so instead of contributing, they took libstrophe and riir 😮‍💨️ Not riir, wiir. Wrap it in rust.

  21. mjk

    yeah, for now. but I was referring to "we plan to create a pure-Rust port of libstrophe"

  22. jonas’


  23. jonas’


  24. moparisthebest

    so, just what nearly 100% of xmpp clients do ?

  25. moparisthebest

    either write their own library from scratch, or fork one and end up maintaining it

  26. singpolyma

    Yeah, I've never understood why almost no client is based on one of the high quality libraries thrt exist. I've always guessed the clients maybe predate the libraries but 🤷‍♂️

  27. moparisthebest

    the only answer that makes sense is because none of the libraries are suitable for making a client

  28. singpolyma

    To be fair I'm going to end up maintaining the two libraries we use,

  29. moparisthebest

    they are great for bots and tools etc but not for clients

  30. singpolyma

    But that's because existing maintainers moved on

  31. singpolyma

    moparisthebest: maybe? But all I want out of a library is do handle the stream and XML parsing and other bog-common stuff. I think maybe many of them try to do too much

  32. moparisthebest

    100% that

  33. Guus

    Ralph has suggested over and over that we should dramatically improve the 'how to get started with library XYZ on platform ABC' documentation. Maybe there's value in that.

  34. Guus

    Giving people better opportunities to figure out that there's pre-existing stuff to re-use, when they start with a new client.

  35. Fishbowler

    That sounds like fun. I'm not well-versed enough to lead something like this, but definitely happy to contribute. Most of my experience is from the server POV, and this looks like a great way to learn more about clientside handling.

  36. Zash

    Related to https://en.wikipedia.org/wiki/Conway%27s_law ? With a small enough group doing a thing, separating it into different projects (e.g. separate client and generic library) creates overhead.

  37. Daniel

    I'm using an xmpp library for a work project and I fairly quickly ran into bugs and things the library didn't let me do that I needed to do. So at this point I would have probably needed to fork the lib to make it better tailored to my needs and fix bugs.

  38. Daniel

    And then I have to understand the architecture and live with the design decisions they made

  39. Fishbowler

    Maybe I might try working with Smack in Java and documenting some progress.

  40. Fishbowler

    Although, as you've pointed out, it might end up as more of a driver for Smack changes than it is for creating a good doc.

  41. flow

    ideally a library provides a sensible amount of low level interfaces and modularity, which allows you to decide in a fine-grained manner which parts of the lib you want to use

  42. flow

    of course, if you only use a tiny bit of the lib, you may as well could just not use the lib at all…