I don't understand the problem. Are they saying that too many of their users are subscribed to too much stuff and when they get throttled (by jabber.org or gtalk) the overhead of keeping track of those in-flight messages overwhelms Gnip's XMPP server?
If that's the case then it points to the one glaring weakness of XMPP. There are very few scalable implementations which also support a wide range of XEPs. For instance XEP 60 (pub-sub) seems to have only 1 usable public implementation: ejabberd
@adewale actually i think they are saying that their users are having a hard time implementing XMPP stuff correctly which results in a lot of extra work for them explaining how stuff works. it's not a technical problem as far as i can tell but a people problem, or only a technical problem in as far that a simple one stop solution (like Apache for HTTP) is missing.
@adewale: I very much disagree with the statement about just one usable implementation. Shameless plug ahead. You might not be aware of Idavoll which I think is (one of?) the earliest implementations of XEP-0060. It is still actively developed, by yours truly, and is actually compliant with the specification, too.
One of the issues with providing XMPP support in services is that there aren't many people who know how deal with non-HTTP and/or asynchronous stuff properly.
In response to @tijs: well, in that case maybe they could have provided working example code. Also, the same applies as to the server-side: people just don't know how to do this stuff yet, and I fully agree with you.
11 comments so far
hmmm
1 year ago by termie
:(
1 year ago by aehn
I always thought XMPP is the new hotness.
1 year ago by till
I don't understand the problem. Are they saying that too many of their users are subscribed to too much stuff and when they get throttled (by jabber.org or gtalk) the overhead of keeping track of those in-flight messages overwhelms Gnip's XMPP server?
If that's the case then it points to the one glaring weakness of XMPP. There are very few scalable implementations which also support a wide range of XEPs. For instance XEP 60 (pub-sub) seems to have only 1 usable public implementation: ejabberd
1 year ago by adewale
@adewale actually i think they are saying that their users are having a hard time implementing XMPP stuff correctly which results in a lot of extra work for them explaining how stuff works. it's not a technical problem as far as i can tell but a people problem, or only a technical problem in as far that a simple one stop solution (like Apache for HTTP) is missing.
1 year ago by tijs
@adewale: I very much disagree with the statement about just one usable implementation. Shameless plug ahead. You might not be aware of Idavoll which I think is (one of?) the earliest implementations of XEP-0060. It is still actively developed, by yours truly, and is actually compliant with the specification, too.
One of the issues with providing XMPP support in services is that there aren't many people who know how deal with non-HTTP and/or asynchronous stuff properly.
In response to @tijs: well, in that case maybe they could have provided working example code. Also, the same applies as to the server-side: people just don't know how to do this stuff yet, and I fully agree with you.
1 year ago by ralphm
@ralphm I'm happy to be corrected. I'm even happier that it's in Python.
1 year ago by adewale
@ralphm http://idavoll.ik.nu/tickets seems to be broken. Or is that Trac's way of telling me there are no outstanding tickets?
1 year ago by adewale
Seems like there is some evangelizing to be done.
1 year ago by aehn
@adewale http://idavoll.ik.nu/report/1
1 year ago by till
@adewale: oh, hmm. That link on the front page has been broken since forever, apparently. Fixed. Thanks for noticing.
1 year ago by ralphm