ok, I'm clueless about when not to use it - I suppose it should not be used in any situation a messaging system is wrong: usually time-bound operations and when you really need synchronous communication - what am I still missing?
1 year, 6 months ago.
Sign in to add a comment
30 comments so far
Large messages and binary data: XMPP is XMLish, so don't send big messages (over 64k will get you in trouble in the larger XMPP federated network).
Negotiate using XMPP out-of-band transfers (several protocols available, pragmatics use HTTP most of the time).
Please note that push-based systems, the ones you'll usually see with XMPP, are always susceptible to slow clients over-runs.
1 year, 6 months ago by melo
@melo: don't you have a post (or collection of posts) on your blog about this issues? Maybe a meta-post acting as kind of a "directory" for it would be a good idea...
1 year, 6 months ago by nunonunes
over-runs could be avoided by server caching/message storing (like for off-line behaviour), or is there some limit on the number of messages/id size that would trump this?
1 year, 6 months ago by jneves
I was thinking of an update/configuration manager for machines - understading if I should manage state of each machine, of if I could trust that a machine that was off for a month would receive all updated messages...
1 year, 6 months ago by jneves
As a server operator, you need to deal with very slow problems. Yes, there is offline messaging and pubsub in XMPP. But the best practices on how to leverage this tools into a more robust messaging bus are still in the pretty clouds.
As I said, the tools are there. But only now people are looking to them on how to leverage them into something reliable.
My "game over" moment for XMPP will be when Browsers have a XMPP stack built-in, so that we can stop with all these push-over-http nonsense.
1 year, 6 months ago by melo
@nunonunes: nope, I don't have that yet.
1 year, 6 months ago by melo
browsers with an XMPP stack? Wow. Why not throw in a Bittorrent client as well? Oh wait...
1 year, 6 months ago by rcarmo
@melo so the browser would be a xmpp client that would subscribe to any open/bookmarked/live bookmarked url and receive notifications of changes?
1 year, 6 months ago by jneves
@rcarmo: as you point out, they already do. But XMPP has a lot more uses than Bittorrent.
1 year, 6 months ago by melo
but XMPP isn't something the man on the street cares about. Go outside and ask someone.
1 year, 6 months ago by rcarmo
@jneves: yes, and other basic push-style interactions. If you have a page open on your ticketing system, the Javascript in there "subscribes" to that ticket, like a "I'm watching this ticket".
If the ticket is updated, the browser is notified and can update the relevant parts of the HTML via ajax.
XMPP is not a HTTP killer, it's a add-on.
1 year, 6 months ago by melo
sorry, wrong reasoning - the conversation is about what I care about ;)
1 year, 6 months ago by jneves
nice - that one would kill a nice chunk of my email...
1 year, 6 months ago by jneves
@rcarmo: neither was HTTP. But I don't care if the "people in the streets" care about it or not. What I care is to have something push in the browser, and right now, XMPP is the best contender.
1 year, 6 months ago by melo
I care only that browser venders think XMPP is a good solution to the push requirements. The rest, I don't care, really.
1 year, 6 months ago by melo
well, I have a name for the plugin: refresh monkey (that's what are when they try to emulate push) - is there a js xmpp client? the rest could start being implemented with a client(server side) integrated with pingback
1 year, 6 months ago by jneves
maybe this: http://zeank.in-berlin.de/jsjac/
1 year, 6 months ago by jneves
It's pooling. Also xmpp4js (http://xmpp4js.sourceforge.net/) - both use the BOSH interface to XMPP (HTTP-based pooling).
So yes, you can have it today, but no, that's not what I want.
Good news is: XMPP stack is in the Google Gears roadmap.
1 year, 6 months ago by melo
ok, understood - thanks for the rundown
1 year, 6 months ago by jneves
For example, I have this page open on my browser: http://jneves.jaiku.com/presence/36460817 why do I need to refresh it when I see a new message via XMPP? because the current solution to pool the jaiku servers would kill them.
Comet is a possible solution until we have real push though. BOSH can use Comet also.
1 year, 6 months ago by melo
I'm thinking of impact - comet (just found out it's something I used years ago) means an open connection per page at the moment - a protocol that would be shared by publishing platforms would be cool - as it's timebound, pubsub with discarded messages would be fine - I wonder if the number of subscription/unsibscription wouldn't kill the server - but I get only trying will help that
1 year, 6 months ago by jneves
that's one of the problems with comet: one connection per page to the origin server. Compare to XMPP: one connection to YOUR own XMPP server. The origin server only has one connection per remote domain.
So all GTalk users accessing your page: one TCP connection to your server.
1 year, 6 months ago by melo
do you think the subscription should be done to a xmpp client (like /@simplicidade.org) or to a notification service?
1 year, 6 months ago by jneves
don't understand the question... The current idea is: add a <meta> tag to you pages specifying a pubsub node in the xmpp network. You client subscribes to that node, and receives Atom document with each update.
Other XML-based documents (even JSON payloads) are of course possible.
1 year, 6 months ago by melo
ok, now I don't understand the answer, but I'm going to read about pubsub and get back to you if any doubts arise...
1 year, 6 months ago by jneves
me thinks melo is on to something. have you spoken with any of the teams behind a web browser to get some early feedback on that?
1 year, 6 months ago by cpinto
nowinf FF people, they would probably ask you to do an add-on as a prototype to check for interess
1 year, 6 months ago by jneves
s/nowinf/knowing/
1 year, 6 months ago by jneves
There is an add-on for FF: http://www.sameplace.cc/
My bet is on Google Gears, actually. They will have an XMPP client, and that will let others try out this thing. Eventually browser vendors will embrace it.
Mind you that HTML5 has something called server-events, that is also targeted at solving the push problem.
1 year, 6 months ago by melo
interesting... i'm definitely setting up some free time to go through that this weekend
1 year, 6 months ago by cpinto