What is Digg?31 Comments
- xqb4dpx, on 01/25/2008, -3/+28XMPP is gonna be ***** sick. Agree?
- chibbell, on 01/25/2008, -2/+18That's a great article. of course he completely glossed over the fact that XMPP finally has a logo!
http://siglerdesign.com/index.php/site/article/xmp ... - metafluence, on 01/25/2008, -1/+15I'm pretty stoked about the future of an Internet based on protocols that are dialogs, not one-way streets. Nice work on this, Matt!
- fabio1, on 01/25/2008, -1/+9i´ve set up a openfire xmpp server about 3 to 4 years ago (jive jabber server at the time, already the best free jabber server by far) and I´ve used to hang around a lot in their forums. Matt always was a nice guy, always listening to his users. It´s nice to see how far Jive has come, and here´s hope that he´s right, and xmpp gets more and more widely deployed. Cheers!
- frakilk, on 01/25/2008, -1/+8Quite an attractive logo it is too.
- Fordi, on 01/25/2008, -0/+5As a coder, JSOMPP is my choice. XML is a bear to parse and traverse, but JSON much less so; it maps easily to software-based data structures, and is flexible enough to provide both quantitative and qualitative data as needed.
Also, XML has a huge bandwidth:data ratio, while JSON's overhead is very light, and compresses better. - metafluence, on 01/25/2008, -0/+4It's been interesting to watch everyone's reaction to Matt's assertion. Some of the comments I'm seeing here on Digg and the Jive post appear that people think Matt is suggesting XMPP replace HTTP, which is not what he's saying. He's referring to it as the protocol of choice for services that require two-way communication. No need to replace a one-way protocol where it's called for, such as downloading a page. Details like optimizing that two-way communication, such as shutting down an inactive port connection, will work out as best-practices. It's all about right tool for the right job, and this is a call to include XMPP in the toolbox with examples for usage.
- scot524, on 01/25/2008, -0/+4We set up a wildfire server about two years ago and it runs really great! Fantastic stuff
- Fordi, on 01/25/2008, -0/+3Of course, this would require a new standard to be added to the W3C list of supported browser protocols.
The problem with all this isn't how to leave a TCP/IP session open; that's easy stuff, and even HTTP does it (keep-alive, anyone?). The problem is that HTTP doesn't have support for a method by which the server can spontaneously introduce additional data in a maintained channel without an additional request.
Mind you, you can 'chunk-hack' HTTP. Basically:
HTTP supports 'chunked' encoding. In this transport method, the server first sends the length of the next chunk, written in hexidecimal, followed by a CRLF. The connection then remains open until the client decides it's timed out, or the server sends the declared length. When the server reports a zero-length chunk, the HTTP session is complete.
So, method. The browser sends an XMLHttpRequest with explicit 'keep-alive' to the server. The XMLHttpRequest is only a placeholder, and will have data when it's available. The server responds with a 1-byte chunk, and repeats this every, oh, 10 seconds to keep the connection open. The XMLHttpRequest doesn't time out, nor does it report an 'all clear' until a zero-length chunk appears. When the server has data, it finishes the chunk, sends a zero chunk to complete the request, and the client sends a new one. Because we've explicitly used keep-alive, this doesn't impose a new TCP connection, but instead just reopens the channel.
*****, that's a good idea. I'm going to go see if I can make it work. - tybris, on 01/25/2008, -0/+3Personally I feel XMPP is going to be the way to build next-generation services in the years to come. At the moment I'm using it for location-based, interactive services for mobile platforms. It essentially provides an overlay network allowing efficient multi-cast, peer-to-peer communication and asynchronous messaging without being bothered by firewalls and the likes. Services can be deployed by anyone as 'chat-bots' which reply to messages and give status updates. Its extensible nature allows you to easily deploy new applications and integrate legacy protocols.
The only thing that is somewhat problematic is that Jabber providers will have to suffer whatever their users come up with. On the long run we can probably expect to see some cost model associated with XMPP. - mweels, on 01/25/2008, -0/+3How can you efficiently have a open channel back to the client though without leaving a TCP/IP session open?
I personally like stateless communication. Much more scaleable. - brd6644, on 09/01/2009, -1/+4The fact that XMPP requires a constant connection means that infrastructures serving a lot of clients will need to be able to handle A LOT of connections at once...
- mattjive, on 01/25/2008, -0/+2You hit on an interesting point here. An XMPP server has to keep an open socket for each client (and it's possible to write a service that handles a LOT, as Google Talk has proven). However, you get great economies of scale with server to server federation. Servers connecting to one another only need one socket. So, I run a service at jivesoftware.com and clients from Google Talk want to consume it, that's only one connection from GTalk and not one for each client.
In any case, when designing an XMPP service it's of course necessary to consider the cost of of open sockets. It's simply my contention that the cost is justifiable for a lot of cloud services vs. polling architectures like SOAP. - tybris, on 01/25/2008, -0/+2That's pretty much like asking what the difference between driving to work and a road is. RPC is Remote Procedure Call, an programmatic architecture in which request message are translate into procedure calls and the return value into a response message. Jabber is a messaging infrastructure consisting of XMPP providers to which clients keep a live connection. Its architecture is very similar to SMTP except that it is meant for live communication and can be easily extended with new protocols.
- mweels, on 01/25/2008, -0/+2What is the difference between RPC and Jabber?
Is this both a transport and payload? - inactive, on 12/22/2008, -0/+1http://www.triplecrownnewsletters.com
http://cleansecolonnow.info - mweels, on 01/25/2008, -0/+1You still have channels open idle, that sucks.
- Fordi, on 01/25/2008, -1/+2What do you think you have with XMPP?
- lispmachine, on 01/25/2008, -0/+1But having lots of dangling connections will just cost some memory for each connection rather than consuming cpu time and bandwidth for pooling.
- tybris, on 01/25/2008, -0/+1No it won't. It will only have to keep a connection per Jabber server (and it may actually close that connection if it is not being used). It's the same architecture as SMTP only the Jabber server keeps a live connection to all of its clients.
- tybris, on 01/25/2008, -0/+1P.S. the communication between the cloud service and the Jabber provider actually is stateless. The only state is between the Jabber provider and its client who keep a live connection, which is not much of a problem.
- tybris, on 01/25/2008, -0/+1Because you only need to connect to the Jabber provider which might have a large number of clients.
- tybris, on 01/25/2008, -0/+1Except that there is no such thing. :-P
Anyway JSON really needs namespaces to be able to compete, but you can still use JSON data within the basic XMPP messages if you want to. All the XML parsing will be done by the XMPP library so you won't have to deal with it. - syphonist, on 02/13/2008, -0/+1"Gonna Be"?? What are you talking about... it already is!
- buywowgoldz, on 07/13/2008, -0/+0'm using it for location-based, interactive services for mobile platforms. It essentially provides an overlay network allowing efficient multi-cast, peer-to-peer communication
http://coolblog.ws/ver468/
http://bugunce.com/ver045/
http://yiqes.com/ver037/
http://ver308.blog-now.net/
http://samahilig.com/ver632/
http://ver024.blogona.com/
http://blog.myfpchat.com/ver425/
http://bugunce.com/ver225/
http://buy-cell-phone-cases.info/ver752/
http://inloop.co.uk/ver480/ - BijuAyyappan, on 02/05/2008, -0/+0I was reading the news about Microsoft's bid for Yahoo! the other day. If the deal goes through, just wondering what impact will that have on the XMPP technology.
Will that be a positive development? - elidourado, on 01/25/2008, -2/+1He's not talking about using XMPP for "cloud computing" services. He's talking about its use for services in the cloud, like Twitter. Rather than having a client poll the server every 3 minutes, the server can just send the client an IM with the appropriate data.
- quellish, on 01/25/2008, -4/+2This is a joke, right? XMPP is a *terrible* choice for "cloud computing" services. XMPP and SOAP are both a poor fit for this type of application - the communication overhead becomes a limiter very quickly.
- killaazn, on 01/25/2008, -5/+2Good stuff. Jive seems to be a leader in the industry, nice to see the so involved. XMPP ftw!
- JasonCox, on 01/25/2008, -6/+2Buried, the AOL switch rumor was debunked within an hour of it getting posted.
Also, at the risk of getting buried, XMPP is not the future of services based on the Internets, the future is in whatever the developer feels will do the job best. That protocol may be open or proprietary. It's their call. - tennisninja38, on 01/25/2008, -13/+430 diggs and already on the main page!
© Digg Inc. 2009
— Content created and posted by Digg users is