jdev - 2022-02-06

I don't think I realized that all the major clients written in python seem to use different libraries. Debating whether it's most beneficial to test against nbxmpp (so that I effectively have integration tests with Gajim) or something else. What other popular clients is it most beneficial to ensure compatibility with?

don't all non-trivial XMPP clients use their own libraries ?

It really does seem so

I guess I shouldn't have been suprised by this; I think I knew what all these used, it had never really hit me though.

even if they don't start out that way, seems like they always end up that way...

I'd love to know why that is; I wonder if it's something about the protocol or something about the size of the community that uses it, or the type of people, etc.

I only have conjecture... almost all XMPP libraries seem massively over-engineered to the point that you can only use them in a very specific way

making them unsuitable to use in a real non-trivial client with even slightly different needs

Oh, how so? I haven't found that to be the case with aioxmpp or slixmpp which are pretty much the only two I've used outside of my own thing or "libraries" that are built into clients and so are obviously tightly coupled

a common pattern I've seen is needing to "register" another "class"+deserializer+serializer for every even slightly different stanza type that might exist

As opposed to just being handed a generic representation of the XML, you mean?

because the library insists on being XML library independent, and/or pretending stanzas are objects and not XML, that kind of thing

well, at least having that option yea

I dunno, it seems like you'd have to do that otherwise you'd have to dig into some arbitrary deeply nested thing and figure out what it is every time. Registering a callback for "normal message with body" or something seems like it would make the users life easier.

right, it's always "well why would a user of a library ever need to do this? it would be so much easier to do it the-way-i-have-in-my-head" and that never ends up matching with someone's GUI library or whatever

Now that you say that, I did design Mellium specifically to allow "just give me a stream of XML and let me do things with it" too, specifically so that you could write your own router/handler thing. But it doesn't seem unreasonable to just require callback.s

yea, I really think the solution is layers, where the library user gets to pick which layers they want

1. connect TLS 2. raw stream 3. separate xml stanzas 4. objects or whatever 5. some type of state management

the XML libs I've seen don't let you go lower than 4 ever, and normally not 5

That's exactly how Mellium works, but FWIW it doesn't always end well either. I can't think what off the top of my head, but I know we've had a few things where we want the connection dialer to know about TLS or something, but they're separate and it's a problem.

it's certainly not an easy solution or it'd already be solved hehe

huh, even the javascript clients seem to use different libraries. Pretty sure this client and this other library are maintained by the same person and the client does its own thing and doesn't use the library (or I'm just misunderstanding JavaScripts many config files, which is more likely)

the 3 problems of computer science, naming, cache invalidation, off by one errors, and the perfectly designed universally used XMPP library

Anyways, turns out it's harder than I expected to pick what the best thing to test compatibility with is. Also the situation in terms of re-usability is more dire than I thought. I am not sure if there are any useful conclusions to draw here or anything useful to do.

unfortunately I think the conclusion is not what you want to hear

it's "don't bother writing a generic XMPP library, no one will use it for anything non-trivial"

useful for a sendxmpp clone or a bot, not for a client though

I'm not sure that's the conclusion; I think the conclusion is "do write a generic XMPP library if one doesn't already exist in your ecosystem of choice, but if one does exist use and improve it in your client instead of writing a builtin tightly coupled one"

could be, but then you'll end up maintaining it, that seems to be what happened with nbxmpp and gajim

If you follow the advise then hopefully other clients show up to help you maintain it though, even if it becomes abandoned and one of the client devs has to pick it up.

But yah, I really don't know how to encourage that kind of participation.

Maybe it's a problem of discoverability too. I probably wouldn't have started Mellium if I realized there was another library already in Go (not counting the one that most people use which is little more than a Google Talk bot framework, you can't use it for serious work). I looked and never found the FluxxIO one and it was a few years before I realized that it had already been a thing.

I really think it's just a GUI thing

writing a GUI XMPP client is 9999x harder than writing a server or a library or a command line sendxmpp

and the assumptions all of us who avoid GUI code like the plague make are just wrong when it comes to writing GUI code

I'm not sure that's true, but I definitely don't write a lot of GUI code, so it's quit possible that I'm doing exactly what you're describing. But I don't see why it would be any easier or harder to write Gui stuff with slixmpp vs. nbxmpp vs. aioxmpp, for example (other than difficulties that would apply to anything due to one or the other library generally being harder or easier to use for various reasons, but I don't see what would be specific to GUI stuff)

Sam, have you ever written GUI code and if so what kind?

I have, but long ago, and Java Swing, and I still have nightmares haha

I'm not counting html/javascript I guess...

Oh yah, I've done a decent bit of GTK, some Android stuff, a bit of web stuff, some immediate mode custom GUIs, some TUI stuff. I don't like it much, and avoid it, but I have done it.

I vaguely remember being forced to memorize various Swing APIs in some terrible intro to CS class in college, but I don't think I ever wrote anything with it after that.

oh yea I've done some old android GUI too but also remember it being terrible

Yah, it's pretty bad.

I don't see how a specific library would necessarily be better or worse with it though.

Android is nicer now. Try androidx compose

No need even for xml

but I like XML !

Then you should try xmp-wait

Xml i think is the wrong form for android uis, but meh, it does work

Compose really is aeons better though, no wonder google absorbed it

Sam: I have been worked on a generic framework for XMPP. The biggest problem for me: it's not such easy. 😬 Lot of things you have to keep in mind to keep it reusable and flexible.

It's almost like there are two kinds of libraries: Those used by exactly one client, and those used by random stuff but no clients.

Zash: exactly what it seems like yes

Smack might be the exception?

Unless whatever Yaxim uses counts as its own library by now 🙂

Zash: libstrophe?

Which one? Which clients?

Zash, slixmpp begs to differ :p

:doubt:

Make directed graph plz.

Libstrophe used by profanity, and my weechat client, as well as i think at least one other?

Also TIL xep 174

Neat