In Full Remote Control mode, several users can share “the same page” (because the state of the page is controlled on the server), any action performed by a user is manifested on the page of the other users. Comet (long-polling) or Ajax based timers (polling) can be used to automatically update the client page to show any change performed by other users in any time.

Check out the Online Demo for more details.

We’ve all seen the typical Comet demos: chat, stock quotes, and system monitoring applications. Hookbox user Salman Haq surprised me with a demo I hadn’t seen before with Comet: a graphical equalizer with its values driven from Comet:

The equalizer source code is quite simple, just using a set of slider widgets client-side, and populating their values with the results returned from Hookbox.

I expect that this is just the first of many creative examples made possible with a simple hosted Comet service.

Hookbox is the web-push server that integrates directly with PHP, Django, Rails, Java servlets, ASP.Net, and any other HTTP-based application framework. Hookbox is Open Source Software under the MIT License. This visual tutorial is ten simple steps that give you a basic idea of Hookbox’s capabilities. It will only take you a few minutes to work through, and no installation is required!

Installation

You can install Hookbox manually, but a much faster way to get started is to create a Hosted Hookbox account. Hosted Hookbox is absolutely free; it is intended for developers to try Hookbox out without investing substantial time and energy. Just remember that you should not run production apps on Hosted Hookbox as it is meant primarily for testing purposes.

Diving in

1. Navigate to the Hosted Hookbox Signup Page and create an account.

   

2. Choose and enter an admin password for your Hookbox instance. Click ‘Save & Restart’.

   

3. Navigate to the Admin Menu option in a new tab and enter the admin password you just chose.

   

4. Now you should see the admin panel. Feel free to explore and see what’s available. There isn’t much going on here yet, but there will be soon.

   

5. At this point you’ve deployed a Hookbox instance and logged into the admin panel. Now we need to try logging in some users. Back in your Hosted Hookbox account page, you should see a ‘Client Test Utility’ link. Open this link in two new browser windows.

   

6. In both Test Client windows, click connect with the given url (it should automatically populate the field with the url for your Hosted Hookbox instance.)

   

7. In each tab, once the client is connected, type test_channel into the Channels name field and click subscribe. Each tab will automatically be assigned a random username when they connect (more on this later).

   

8. Now you can publish messages back and forth between the two connected clients. Go ahead and open up multiple Test Client instances, and feel free to use multiple browsers/machines. You’ll be able to see the list of connected clients in the Presence section, and all channel events (publish, subscribe, unsubscribe) in the History section.

   

9. Open up the tab where you are logged into the admin panel. Select Channels and then click test_channel.

   

10. This view allows you to monitor and administer the channel. Here you can modify channel options, remove users, publish messages, or simply watch.

    

    Try publishing a message from the admin panel and watch it appear in the Test Client pages immediately.

    

What about my web app?

This ten step tutorial shows how a client can interact with Hookbox. Adding web app integration is also trivial; in fact, the demo you just played with is integrated with a Django application. In particular, you’ll notice the “Simple Callback URL” field in the Hosted Hookbox account page. Anytime Hookbox sees an event such as someone connecting, subscribing, or publishing, it sends an HTTP request to that callback URL asking for permission for the action. The web application hosted at that callback URL is passed various parameters in the form, such as the type of action, the channel_name, the user name, or the payload.

You can actually see exactly what the default callback URL does. For instance, when you connect from the Test Client page, Hookbox sends a connect callback to the URL: http://hosted.hookbox.org/test_callback?action=connect. If you open this URL in a new tab, you’ll see a response like:

[true, {"name": "qihagi"}]

This is where those random user names come from. Hookbox does not generate the usernames; rather, the web app — powered by Django in this case — provides the name for each user that connects to Hookbox. In a production application, we would have used Django’s sessions to determine the username and authorize the connection.

Try http://hosted.hookbox.org/test_callback?action=create_channel& channel_name=test_channel to see how the web application authorizes Hookbox to create a channel. You should see a response like:

[ true, { "history_size": 20, "reflective": true, "presenceful": true } ]

You can see a log of all interactions between Hookbox and your web application by opening the Webhook Logs section of the admin panel

Additionally, the web app can interact with Hookbox via the REST API. Navigate back to the Hosted Hookbox screen, enter a Rest Secret, and click Save & Restart. The Test Client and admin panel do not automatically reconnect, so you’ll have to refresh/reconnect the window(s) running the Test Client and re-login to the admin panel. The Rest Secret is a token shared between the web application and Hookbox; it is passed in the querystring of any REST call to Hookbox. Lets try one. Assuming my Hosted Hookbox name is “mcarter5″, and my rest secret is “abc”, then I can publish to test_channel by requesting the following URL:

http://mcarter5.hosted.hookbox.org/rest/publish?payload="hello from REST"&channel_name=test_channel&secret=abc

Go ahead and alter the url to fit your username and secret rest key and try it out. It will publish the message to your test clients, and you should see a response like:

[ true, {} ]

Another REST call to try is get_channel_info:

http://mcarter5.hosted.hookbox.org/rest/get_channel_info?channel_name=test_channel&secret=abc

You should see a response like:

[
   true,
   {
      "name":"test_channel",
      "subscribers":[
         "hafiwo"
      ],
      "options":{
         "moderated_publish":false,
         "moderated_unsubscribe":false,
         "polling":{
            "url":"",
            "originator":"",
            "interval":5.0,
            "mode":"",
            "form":{ }
         },
         "state":{ },
         "moderated_subscribe":false,
         "moderated":true,
         "anonymous":false,
         "history_size":20,
         "reflective":true,
         "presenceful":true,
         "history":[
            [ "SUBSCRIBE", {
                  "user":"hafiwo",
                  "datetime":"2010-07-26T04:05:59"
               }
            ]
         ]
      }
   }
]

You can find more information about these calls at the Hookbox REST Documentation.

JavaScript integration

To use Hookbox with your app, you need to include hookbox.js. It is served from your running Hookbox server at /static/hookbox.js (or hookbox.min.js,) but you can also download it and serve it from your web app if you like. For example, my hookbox.min.js is served at http://mcarter5.hosted.hookbox.org/static/hookbox.min.js. The API provided by hookbox.js is straightfoward: There are methods to connect, subscribe, unsubscribe, publish, and disconnect. There are callbacks for when other users perform these actions. You can read more about this from the Hookbox JavaScript Documention.

Conclusion

Hookbox can be used to create all manner of real-time web apps. It is particularly well suited to the following:

• Chat (presence, rooms, history, and the whole nine yards)
• Stock feeds
• Real-time data monitoring graphs / feeds
• Multiplayer taking-turns-style games (cards, chess, trivia, backgammon, etc.)
• Real-time administration / monitoring panels
• Push-notified blog comments

The Webhook callback and REST interface allows you to use absolutely any HTTP-based application framework/language. You don’t have to learn a new way of writing applications just to make them real-time. Simply design a web application as you normally would, and then use the Hookbox APIs to integrate real-time features!

The major additions in this release match many of the recent improvements in cometD 2.0 and more including:

• The use of WebSockets in the browser where supported
• Compatibility with cometD servers and clients
• An extension API to layering extra functionality onto the server and client
• Handling multiple subscriptions per channel
• Improved handling of network dropouts and server restarts

More information is available on James’ blog, and on the Faye website.

Read the full Real-time Comet Applications on Node with Tunguska post for more details.

The core Bayeux protocol is unchanged, so cometD 1 and cometD 2 are interoperable at the protocol level. cometD 2 provides a completely revised Java API, with the goal being a simplified API. Applications written with the cometD 1 APIs needs to be ported to the CometD 2 APIs, but the concepts are the same.

cometD 2 has been rewritten from scratch, and JDK 6 is now a requirement (though there is some discussion about backporting it to JDK 5 with somewhat degraded performance), and extensively using JDK’s concurrency features making CometD 2 very scalable.

The other major update is that cometD 2 now supports WebSocket, both on the server (as one of the available transports) and on the client (in the JavaScript library - not yet in the Java client). Browsers such as Safari 5+, Chrome 5+, and Firefox 4+ that support WebSocket can communicate with the cometD server even more efficiently.

Documentation is on its way; an initial migration guide is available and more will follow.

Updated examples and demos are available in the cometD 2.0 distribution tarball.

Congratulations to Simone Border, Greg Wilkins, and the other contributors that made this release possible!

What is Comet, really?

When I think of Comet, my mind immediately jumps to the idea of the “real-time web”, which is probably what the majority of Comet developers think about as well. Live updates in a web browser, awesome! But recently, I’ve seen more and more people using WebSync to solve other problems, and for many applications that are not strictly web-based. These applications may be *partially* web-based, but often times they have other components as well - desktop, mobile devices, you name it.

Comet is, in my opinion, much more than just a way to push data to a web browser. It’s a complete platform for real-time communication, built on top of HTTP, for all languages and purposes, not just the web.

A multitude of devices

When I was at the University, my design project was an application for managing equipment within a nano-fabrication lab on campus. It had a web front-end for managing users and devices, a Windows CE component to send signals to the switch, and an ethernet-enabled relay switch for actually controlling the various pieces of equipment. This was, overall, a very small project. But it already had 3 separate components and required programming in 2 software languages and some hardware design as well.

Fast forward to today. Applications aren’t getting any simpler. More people and businesses want devices that can communicate between the web, desktop, and mobile devices, and Comet is ideally suited to doing exactly this! Since Comet runs over HTTP, you can typically side-step any issues with firewalls, network configurations, etc. Additionally, if your server is based on open standards (such as the Bayeux protocol), integration with other languages and platforms becomes a snap - WebSync, for example is able to communicate with applications build on Windows Forms, Windows CE, Windows Phone, JavaScript, Silverlight, PHP, and we’re considering Java too (although since the cometD project has already written a Java client for their Bayeux implementation, that client should work with WebSync as well). With Comet (and Bayeux in particular) at the center of your communication, the sky is truly the limit. Let those Windows Phone Apps talk to your web apps, and throw in a notification system to sit in your system tray while you’re at it.

Comet can actually become the foundation on which your entire application is built, tying all these pieces together into one seamless unit!

A communication platform

To me, this is all rather amazing, really. When we started building WebSync, we were building a solution to a problem we needed to get past ourselves - pushing data to a web browser in real time using ASP.NET and IIS. By solving that problem, we’ve actually created a whole communication platform, with all kinds of integration points and incredible extensibility. What are your thoughts on using Comet as more than just a simple browser-push solution?

Quick Bullet points about CSP

• Provides a bi-direcitonal, client <–> server stream
• Well specified
• Works in all browsers without plugins
• Traverses all intermediaries for http and https (proxies, firewalls, anti-virus, etc.)
• Architectural WebSocket drop-in for older browsers

The protocol specification describes how a client and server can establish a reliable, bi-directional stream on top of HTTP. The protocol is designed to be implemented in browsers with JavaScript for the client, and on top of existing HTTP implementations for the server. CSP should be thought of as a transport-level technology, similar to TCP, so client and server libraries expose a socket-like interface. For instance, in Twisted/python you would define a Protocol and Factory class in order to implement a protocol, then at run-time you would expose that protocol over TCP by calling something like:

reactor.listenTCP(MyFactory(), ...)

With the Twisted/python CSP implementation you would take the exact same steps, except at run time you would alternatively (or additionally) call something like:

reactor.listenCSP(MyFactory(), ...)

and like that your TCP-based protocol implementation is now exposed to the web. CSP is not meant to replace either TCP or WebSocket, but to co-exist with both. You might have one server that listens for all three protocols if you were targeting desktop/mobile, Chrome/Safari, and Internet Explorer.

The specification is still relatively young, but implementations of CSP have been in production for almost a year now. The best client implementation at this time is js.io; multiple server implementations exist, including csp_eventlet, csp (twisted), and js.io (runs on top of node.js).

The panel will be moderated by me, and will include panelists representing the following projects:

• APE
• cometD-Jetty
• DWR
• Liberator
• Lightstreamer
• Meteor
• WebSync

We’re also hoping to get a few more projects represented. Please sign-up to attend as space is limited. And if you cannot make it to London, fear not, as video will be online shortly after the event.