nextwebgen.com

The Next Generation Web Now

Cross Domain Comet

Filed under: Web 2.0 News, Front Page, Comet — Dion Almaer at 9:42 am on Wednesday, July 26, 2006

Adding on to the last post on cross domain XHR, Cometd now supports working across domains, without plugins.

Alex Russell explains:

By building on top of the Dojo ScriptSrcIO infrastructure it was trivial to make a JSONP transport for Cometd. We just adapt the long-poll style of Comet but make the initial handshake messages JSONP-clued. That in place, the rest works just like “normal” long-polling, except that the client can connect from any domain. The configuration problem just dropped from “make sure everything cooperates at the systems and network level” to “make sure that the client and server speak the same protocol”…and I like solutions that put the problem in software and not external configuration or human effort.

So what’s the downside? The first downside is that the latency characteristics for cross-domain Comet using this technique are the same as long-polling. Not bad, mind you, but not as optimal as iframe, multipart-mime, or Flash-based solutions when you have large numbers of messages being thrown at the client. Additionally, it’s more difficult to know when a connection “times out” or in some other way fails, but I think these are tractable. Having a Plan A and a Plan B for cross-domain Comet and a server that can speak both styles via pluggable transport wrappers is exciting to me. By lowering the configuration barrier, I think we’ll start to see a significant uptick in Comet adoption.

Asteroid: Seaside Comet Implementation

Filed under: Web 2.0 News, Front Page, Library, Comet — Dion Almaer at 9:46 am on Friday, July 21, 2006

Diego Gomez Deck has written an Comet implementation in Seaside (Smalltalk continuations based web framework) called Asteroid.

Features

  • JSON-rpc implementation
  • disconnection handled in browsers
    • manual reconnection
    • automatic reconnection working in IE
  • visual feedback (using script.aculo.us)
    • rpc
    • connection/disconnection
    • events reception

View a demo

Juggernaut: Comet for Rails?

Filed under: Web 2.0 News, Front Page, Toolkit, Ruby, Comet — Dion Almaer at 8:41 am on Thursday, July 20, 2006

Alex MacCaw has released a plugin for Ruby on Rails that “aims to revolutionize your Rails app by letting the server initiate a connection and push data to the client. In other words your app can have a real time connection to the server with the advantage of instant updates.”

The plugin Juggernaut initiates a flash xmlsocket between server and browser allowing real time communication between the two. The open socket connection allows the server to ‘push’ base64 encoded javascript to the browser which is subsequently decoded and evaluated.

I see this as Comet for Rails, as it is about the interaction model not technology (e.g. if Flash or not). Alex may disagree :)

Frequently Asked Questions

What flash version does Juggernaut use?

Flash socket uses version 6 which is supported by more than 95% of users.

Does it work in all browsers?

It works in all the major ones: Firefox 1+, IE 6+ and Safari 2+.

What are the advantages/disadvantages of using a flash socket over other methods?

It’s better than comet because:

  • It’s much less of a hack
  • It doesn’t crash your browser (Comet can do this after a while)
  • 95% of browsers support it (flash 6).
  • It’s much easier to implement
  • It can use a different port - unlike comet - so you don’t need any custom dispatch servlets for forwarding messages through rails to the push server - it can connect directly.

It’s better than polling because:

  • Much cleaner
  • Doesn’t use as many server resources

Cometd: Bringing Comet to the Masses

Filed under: Web 2.0 News, Front Page, Framework, Comet — Chris Cornutt at 8:06 am on Friday, July 14, 2006

As was briefly mentioned in this previous post, there’s a framework in development for those users out there looking to the skies and wanting to use Coment - Cmoetd.

Cometd is a scalable HTTP-based event routing bus that uses a push technology pattern known as Comet.

The frameork, previously named “ShortBus” is a collaboration between Teknikill Software and Shadowcat Systems to provide a simple, light method for users to easy integrate the Comet technology into their applications. The site’s a little light on the information (and documentation), but there are some slides/images to help clear things up a bit:

You can also check out the Cometd Development Group and Users Group over on Google.

Two-Way Web: Can You Stream In Both Directions?

Filed under: Web 2.0 News, Front Page, Remoting, Comet — Michael Mahemoff at 6:42 pm on Thursday, July 13, 2006

Comet is mostly considered a server-to-browser thing, but how about a permanent connection in the opposite direction, from browser to server? I’ve been talking about this on my blog and received some interesting thoughts from Alex Russell.

There are two key issues:

(1) Server needs to start outputting before incoming request is finished. With a specialised server, this problem could be overcome.

(2) (More serious as we can’t control the browser) The browser would need to upload data in a continuous stream. You can do it with Flash/Java, but I can’t see how to do this with standard JS/HTML. If you use XHR, you’re going to call send() and wave goodbye to the entire request…there’s no support for sequencing it. Same if you submit a regular form, change IFrame’s source etc. Even if you could somehow delay reading of content so it’s not immediately uploaded, the browser would probably end up not sending anything at all as it would be waiting to fill up a packet.

Now I’ve seen various people mention the possibility of HTTP keep-alive, but I’ve never actually seen any concrete demos or techniques to take advantage of it from a script. So if you know of any …

Anyway, Alex Russel says it’s probably not possible, but we can get around it anyway:

So I’ve spent some time investigating this (as you might expect), and at
the end of the day there’s not much to be done aside from using Flash
and their XMLSocket interface. That’s an obvious possibility given the
high-performance Flash communication infrastructure we have in Dojo.
Doing bi-directional HTTP probably won’t happen, though, but I don’t
think that’s cause for despair. In my tests, we can get really good
(relative) performance out of distinct HTTP requests so long as the
content of the request is kept to a minimum and the server can process
the connection fast enough. HTTP keepalive exists at a level somewhat
below what’s currently exposed to browsers, so if the client and server
support it, frequent requests through stock XHR objects may verywell be
using it anyway. We’ll have to do some significant testing to determine
what conjunctions of servers/clients might do this, however.

As an interesting side note, he also pointed to some work going on at http://cometd.com to build an open Comet protocol.