Reply to XMPP version requests

[jabbercat]

Reply to XMPP version requests

[mrDoctorWho]

Is that really a thing for an xmpp library?

I think a library should have the very basics, like stanza parsing/building, callbacks for asynchronous stuff and incoming stanza, and connection helpers.

Probably I've been using xmpppy for too long, which only does the above. I suggest you to not making your library a giant mess that does everything someone would rather implement themselves.

I'm saying that from a point, where I should have given up a giant library because it was doing something wrong, not the way I needed. For example, I gave up on the requests library and wrote an analogue to it myself, because of a huge lot of dependencies it had and that it sometimes detected the input encoding wrong.

In my opinion, it is better to do this in jclib.

Edit: tenses

[horazont]

Agree to disagree. aioxmpp is intentionally meant to support very high-level features. Of course, you can do everything on your own, you’re free to do that (just don’t summon any services, or only summon your own services).

The rationale for this is (and this should probably go into the aioxmpp docs) that many XMPP things are hard to get right. aioxmpp aims to take that load off your back, if you’re willing to accept the help (again, you’re free to not use any built-in services and use aioxmpp only up to the StanzaStream, heck, you could even use it only up to the XMLStream, but I really don’t recommend that).

A good example of things hard to get right are bookmarks (or really anything Private XML Storage-y or similar PEP protocols). To store a bookmark, you essentially have to do a "read, modify, write, test" loop until your changes have been applied (if concurrent access with different clients happens, they may overwrite your changes. This algorithm converges eventually.). This is tricky to do right, so we handle this in aioxmpp in a BookmarkClient service.

By providing these services in aioxmpp, we centralize the code for complex and non-complex XEP implementations. This centralizes the bugs, and the place to fix them. Since most XEPs have very straightforward interfaces, I see no reason to not provide them in aioxmpp.

(Note that just because we implement version request handling in aioxmpp, no aioxmpp user is forced to: (a) load the service at all, so they’re free to implement their own solution, or (b) reply with a specific version (the service of course would have properties to configure the reply).)

jclib really mostly is the multi-account glue on top of aioxmpp. Multi-account can be done very differently (to name only a single area of choice: merge vs. separate rosters) and also depends on some basic UI choices (to stay with the roster example: a nested tree vs. the tag approach), which is why it doesn’t make sense to handle that in aioxmpp.

[horazont]

Created horazont/aioxmpp#163 for this.

[horazont]

Fixed with 88d015f.