5 ms·

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it a

by creshal 11y ago

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.

pyre 11y ago
What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
- leonroy 11y ago
  Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
  - pyre 11y ago
    > chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
    - Qwertious 11y ago
      Sounds like XMPP isn't the solution then, only {???,XMPP} is.
      - pyre 11y ago
        Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)
        creshal 11y ago
        There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
        leonroy 11y ago
        Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).
        davecridland 11y ago
        What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.
        leonroy 11y ago
        Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated. Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'. Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support). I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
- taurath 11y ago
  Adium has a UX and UI from the 90s, for one.
leonroy 11y ago
btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.
- scrollaway 11y ago
  What are the advantages of OpenFire over ejabberd/prosody?
  - leonroy 11y ago
    Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc. Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment. It also does need at least 512MB RAM which rules it out on embedded devices.
- creshal 11y ago
  I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.

by creshal 11y ago

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.

pyre 11y ago

What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.

leonroy 11y ago
Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
- pyre 11y ago
  > chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
  - Qwertious 11y ago
    Sounds like XMPP isn't the solution then, only {???,XMPP} is.
    - pyre 11y ago
      Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)
      - creshal 11y ago
        There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
        leonroy 11y ago
        Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).
        davecridland 11y ago
        What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.
        leonroy 11y ago
        Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated. Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'. Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support). I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
taurath 11y ago
Adium has a UX and UI from the 90s, for one.

leonroy 11y ago

btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.

scrollaway 11y ago
What are the advantages of OpenFire over ejabberd/prosody?
- leonroy 11y ago
  Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc. Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment. It also does need at least 512MB RAM which rules it out on embedded devices.
creshal 11y ago
I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.