It's unfortunate that technologists continue to propagate serious mistakes like "[...] its also clear that REST and its inherent polling mechanism isn't the best way of building a user notification system [...]"
REST is about state transfer - and event notifications are also state transfer.
As for HTTP, it isn't only "polling" - anyone that has posted a blog entry knows that. The 'client' can 'post' updates to the 'server' - exactly the same as event notifications via XMPP. The great thing about XMPP is the federated multi-hop capability with 'trust' built-in. Just like email, only with everyone using settings for very low latency delivery.
There have been multiple publish/subscribe over HTTP mechanism (comet, mod_pubsub, KnowNow, etc) over the years.
Showing posts with label Ajax. Show all posts
Showing posts with label Ajax. Show all posts
July 24, 2008
March 08, 2006
Alex Russell on Comet
From Phil Windley - this a
very good summary of the web-native event notification system that has evolved from Ajax - Comet. It hits all the points that KnowNow dealt with five or six years ago.
One nitpicking point is this "The problem is that each connection takes a process or thread and there might be thousands of them. Comet can reduce load but not on your current Web infrastructure." A server doesn't necessarily have to allocate a thread or process for each connection - if you look at IRC servers, they handle many thousands of concurrent connections. What is needed is non-blocking IO and Phil's post later points to SEDA - staged event driven architecture. Which brings this full circle from my work at KnowNow that used persistent connections to the browser, to my team at Amazon that used SEDA in a new real-time publishing system we built over the past few months.
It's great to see everybody up to speed on internet-scale event notifications - the power of event driven browser applications is now clear, XML messaging via Atom/RSS is widespread, even Microsoft has contributed algorithms for supporting messages criss crossing a cross-linked web of subscriptions. What's next? I think the 2-connection limit needs to be solved and that will be the final step in the next wave of live Web apps.
very good summary of the web-native event notification system that has evolved from Ajax - Comet. It hits all the points that KnowNow dealt with five or six years ago.
One nitpicking point is this "The problem is that each connection takes a process or thread and there might be thousands of them. Comet can reduce load but not on your current Web infrastructure." A server doesn't necessarily have to allocate a thread or process for each connection - if you look at IRC servers, they handle many thousands of concurrent connections. What is needed is non-blocking IO and Phil's post later points to SEDA - staged event driven architecture. Which brings this full circle from my work at KnowNow that used persistent connections to the browser, to my team at Amazon that used SEDA in a new real-time publishing system we built over the past few months.
It's great to see everybody up to speed on internet-scale event notifications - the power of event driven browser applications is now clear, XML messaging via Atom/RSS is widespread, even Microsoft has contributed algorithms for supporting messages criss crossing a cross-linked web of subscriptions. What's next? I think the 2-connection limit needs to be solved and that will be the final step in the next wave of live Web apps.
March 06, 2006
Comet - event driven Ajax arrives
This
Ajaxian post introduces the name 'Comet' to describe an event-driven approach which is a natural evolution of Ajax applications. It's been great to see so many applications use Ajax and the recent appearance of 'unsolicited message delivery' to browsers is also very cool. There have been a few groups doing this for many years, and it's exciting to see it all about to really take off and become fully mainstream.
The remaining technical hurdle for this technology is the client-side 2 connection limit - at KnowNow we used a 'journal' topic to funnel all messages through, but I don't know what others are doing. I'm going to guess that browsers will soon move this to 4 or more connections. It may be necessary for some deep thinkers to analyze the TCP/IP issues and address it at the protocol level, but I hope not.
Just the other week, I built a simple servlet at work that delivers messages into a browser using a persistent connection. I hooked the servlet to our recruiting/resume pipeline, so now my team gets live notifications the moment a candidate is entered into the system - we now beat out other groups in tagging the candidate and get first choice of many more people. A simple tool, but super useful and it only took a few hours of work, compared to a few weeks of work back at KnowNow so many years ago. Having a built-in XML parser on the client and a robust browser (Firefox in my case) takes care of most of the client infrastructure.
The thing I like about my simple messaging server and client is that it uses hyperlinks identify the set of messages and the client simply 'follows the links' to get more messages. When a client gets to the end of the list of messages, the servlet holds onto that request until more messages arrive - at which point they flow down to the client, achieving fairly low latency. The implementation isn't scalable or efficient, but the approach of using hyperlinks is.
Here's an example chat app (don't expect greatness...)
Ajaxian post introduces the name 'Comet' to describe an event-driven approach which is a natural evolution of Ajax applications. It's been great to see so many applications use Ajax and the recent appearance of 'unsolicited message delivery' to browsers is also very cool. There have been a few groups doing this for many years, and it's exciting to see it all about to really take off and become fully mainstream.
The remaining technical hurdle for this technology is the client-side 2 connection limit - at KnowNow we used a 'journal' topic to funnel all messages through, but I don't know what others are doing. I'm going to guess that browsers will soon move this to 4 or more connections. It may be necessary for some deep thinkers to analyze the TCP/IP issues and address it at the protocol level, but I hope not.
Just the other week, I built a simple servlet at work that delivers messages into a browser using a persistent connection. I hooked the servlet to our recruiting/resume pipeline, so now my team gets live notifications the moment a candidate is entered into the system - we now beat out other groups in tagging the candidate and get first choice of many more people. A simple tool, but super useful and it only took a few hours of work, compared to a few weeks of work back at KnowNow so many years ago. Having a built-in XML parser on the client and a robust browser (Firefox in my case) takes care of most of the client infrastructure.
The thing I like about my simple messaging server and client is that it uses hyperlinks identify the set of messages and the client simply 'follows the links' to get more messages. When a client gets to the end of the list of messages, the servlet holds onto that request until more messages arrive - at which point they flow down to the client, achieving fairly low latency. The implementation isn't scalable or efficient, but the approach of using hyperlinks is.
Here's an example chat app (don't expect greatness...)
November 24, 2005
ahah - So that's how it's done
The microformats.org wiki has a discussion about AHAH (Asychronous HTML and HTTP) that describes an interesting approach to building dynamic pages - but I can't help wondering why the browser developers (like the WHAT-WG) just don't implement client-side includes? Something simple like <div src="latest.html" /> This avoids the need for client side script and ensures the browser can correctly manage connections, caching, authentication, etc.
June 02, 2005
Adam on Ajax
A little bit of a retrospective on dynamic pages and Ajax from Bosworth - Ajax reconsidered.
Dig this - network events into the browser... who'd a thunk it? (Other than the half dozen companies doing it over the past five years.)
Dig this - network events into the browser... who'd a thunk it? (Other than the half dozen companies doing it over the past five years.)
Secondly, the browser isn't a good listener to external events. If you want to build an application, for example, to show you instantly when someone bids or a price changes, it is hard. You can poll, but poll too frequently and the application starts to feel sluggish and it isn't easy to do this. What you really want is an event driven model where in addition to the events like typing the page can describe events like an XMPP message or a VOIP request or a data-changed post for an ATOM feed.
May 25, 2005
Messaging with Ajax and ActiveMQ
From the Ajaxian Blog:
Messaging with Ajax and ActiveMQ
This is just so very cool. Very much like the Destiny servlet I built from several years ago - only this has a browser based client and bundled with ActiveMQ.
Messaging with Ajax and ActiveMQ
This is just so very cool. Very much like the Destiny servlet I built from several years ago - only this has a browser based client and bundled with ActiveMQ.
March 21, 2005
XMLHttpRequest - the Return of the King
It's amazing what fundamental technical innovations can lay around waiting to flower at the right time. Like seeds in Death Valley sprouting after a rainstorm, the sturdy little XMLHttpRequest object in Web browsers is taking the world by storm. Here's a page from Fiftyfoureleven.com with a large list of links of people and projects based on XMLHttpRequest -
XMLHttpRequest & Ajax Based Applications.
This is great stuff. I wonder what it was that finally made this explode onto the Web developer scene. It's been around at least five years in InternetExplorer - but I suppose it was languishing until the rest of the community got around to implementing it. I'd love to see a timeline of it's deployment in other browsers and it's adoption.
I wonder what all this attention to 'no refresh' web apps will do for mod-pubsub. I wonder if mod-pubsub is even still breathing, since they ought to be all over this and figure out how to use XMLHttpRequest to parse a streaming response and then kick messages into their javascript client-side router.
(later) Ah, I see now the connection between Ajax and KnowNow.
XMLHttpRequest & Ajax Based Applications.
This is great stuff. I wonder what it was that finally made this explode onto the Web developer scene. It's been around at least five years in InternetExplorer - but I suppose it was languishing until the rest of the community got around to implementing it. I'd love to see a timeline of it's deployment in other browsers and it's adoption.
I wonder what all this attention to 'no refresh' web apps will do for mod-pubsub. I wonder if mod-pubsub is even still breathing, since they ought to be all over this and figure out how to use XMLHttpRequest to parse a streaming response and then kick messages into their javascript client-side router.
(later) Ah, I see now the connection between Ajax and KnowNow.
March 16, 2005
UI Design Is Different with XmlHttpRequest
From Phil Windley - UI Design Is Different with XmlHttpRequest. There has been a ton of great stuff recently coming from XmlHttpRequest - it's hit the tipping point. I really enjoy seeing mature consideration of the possibilities - when Jakob Nielsen starts grumbling about it, you know it's arrived.
I'd love it if someone did a background story on who created that and got it added to IE4. When I first saw it four or five years ago, I said "This is the most important thing to happen to the browser since the browser." At DataChannel, a buddy quickly moved on it and implemented a Java version with the same interfaces in an applet we had that supported XML parsing and XSLT transformation - remember, this was before anyone had XML parsers in the browser.
I think XmlHttpRequest will go down as a major innovation on par with the browser itself.
I'd love it if someone did a background story on who created that and got it added to IE4. When I first saw it four or five years ago, I said "This is the most important thing to happen to the browser since the browser." At DataChannel, a buddy quickly moved on it and implemented a Java version with the same interfaces in an applet we had that supported XML parsing and XSLT transformation - remember, this was before anyone had XML parsers in the browser.
I think XmlHttpRequest will go down as a major innovation on par with the browser itself.
March 03, 2005
Amazon Zuggest
Oh, gawd. Somebody built a nice example of a live browser based search against Amazon's catalog. If this takes off, it might even add a bit more load on the servers.
The app is neat, but search results aren't different by letter, so maybe searching on whole words instead would be better. And use fixed width tables so things don't jump about so much.
The app is neat, but search results aren't different by letter, so maybe searching on whole words instead would be better. And use fixed width tables so things don't jump about so much.
Subscribe to:
Posts (Atom)