XSF Discussion - 2022-11-10

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

I will likely summarize a bit of my work

emus, what's the venue?

Via jitsi I believe. I will announce more officially later

which jitsi? :-)

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

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

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

https://prose.org/

so Poezio has an antagonist :)

...and Roezio a friend

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

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

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

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

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

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

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

derp

huh

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

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

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 🤷‍♂️

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

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

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

But that's because existing maintainers moved on

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

100% that

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.

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

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.

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.

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.

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

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

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.

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

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