4 ms·

Okay, I get that IRC isn't able to convey lots of modern fancy stuff, but XMPP? Really? I swear, it can do almost anything that fits into stanza exchange logic,

Okay, I get that IRC isn't able to convey lots of modern fancy stuff, but XMPP? Really? I swear, it can do almost anything that fits into stanza exchange logic, as long as one's not afraid of adding an XML namespace (of course, it's being nice to search for already existing XEPs first). Afterwards it's client developers' problem to support shared threaded animated gif sticker emoji reactions or whatever.

u801e 9y ago
The one problem I had with the XMPP gateway is that it would lock up my client for several minutes while trying to connect. I don't have that problem when using the IRC gateway. But at least I didn't have to deal with inline images and animated gifs over the gateway.
dmitriid 9y ago
> Afterwards it's client developers' problem Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...? There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.
- drdaeman 9y ago
  XMPP is a protocol. Slack's own RTM API is a protocol. It was claimed that the former cannot be extended but the later can be - which I argued is wrong. Now you're arguing about something completely different. It's not like it's a death sentence if some RTM API-consuming app is not capable of something - why does it suddenly becomes an issue when we switch protocol to XMPP?
  - dmitriid 9y ago
    Because Slack both develops the protocol, and provides apps for all platforms that support all features in this protocol. There’s exactly one XMPP client (Conversations for Android IIRC) that supports all the XMPP features (many of them in still experimental XEPs) that make it barely suitable for a modern mobile-heavy world, much less for anything else. So yes. When you say it’s developers’ problem to develop clients, it’s not. It immediately becomes the end-users’ problem.

u801e 9y ago

The one problem I had with the XMPP gateway is that it would lock up my client for several minutes while trying to connect. I don't have that problem when using the IRC gateway. But at least I didn't have to deal with inline images and animated gifs over the gateway.

dmitriid 9y ago

> Afterwards it's client developers' problem Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...? There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.

drdaeman 9y ago
XMPP is a protocol. Slack's own RTM API is a protocol. It was claimed that the former cannot be extended but the later can be - which I argued is wrong. Now you're arguing about something completely different. It's not like it's a death sentence if some RTM API-consuming app is not capable of something - why does it suddenly becomes an issue when we switch protocol to XMPP?
- dmitriid 9y ago
  Because Slack both develops the protocol, and provides apps for all platforms that support all features in this protocol. There’s exactly one XMPP client (Conversations for Android IIRC) that supports all the XMPP features (many of them in still experimental XEPs) that make it barely suitable for a modern mobile-heavy world, much less for anything else. So yes. When you say it’s developers’ problem to develop clients, it’s not. It immediately becomes the end-users’ problem.