I’m working on the rich UI of a small web application which has a problem I need to solve: the data from the server which the UI is presenting could change at any time. The first iteration of the UI has a refresh button. Clicking this button sends an Ajax request to a resource on the server which responds with a JSON data structure, and the UI is updated with any changes in the new data. My business partner doesn’t like the refresh button; he questions why it’s there and states how annoying it is to press the button all the time. His suggestion is the rich UI should smartly poll the server for changes to the data, and update the UI automatically.
Intrigued by his idea, we continued our discussion leading to a definition for what it means to smartly poll a server’s resource:
- Use conditional GET requests
- Retain the most recent Etag and Last-Modified date of the polled resource
- Disable polling when the browser window is inactive
Implementing a smart polling process in our application’s rich UI gives us some desired benefits:
- Removal of the refresh button
- Automatic updating of the UI when the resource on the server has changed
- Less repainting of the page since the DOM is touched only when the data has changed
- Changes to the UI only happen when the window is active (the user sees them) as polling is paused while the user is doing something else
Creating a reusable component to achieve a smart polling process feels like the correct approach as I foresee a need to use this functionality in future projects as well. Continue reading ‘Smart Polling’
Sun Microsystems now has a cloud-based computing business. Not only are they going to start offering cloud-based services similar to that of Amazon AWS and Rackpsace Mosso; they’ve also released a Cloud API specified with RESTful HTTP and JSON. Maybe more interesting than the technology choices, is that Sun is releasing it as an open-source project licensed with Creative Commons Attribution.
Tim Bray, the Director of Web Technologies at Sun Microsystems, blogged about his involvement developing the API:
The Sun Cloud: “This is a unified view of the storage and compute and networking services. It’s built around the notion of a ‘Virtual Data Center’ (VDC), which contains networks and clusters of servers and public IP addresses and storage services. The idea is to give you the administrative and operational handles to build something really big and ambitious. The VDC notion is really slick and I think something like it is going to be required in any serious cloud API going forward.
At the bottom level, the interface is based on HTTP and tries hard to be RESTful. All the resources—servers, networks, virtual data centers—are represented in JSON. [Don’t you mean XML? -Ed.] [Nope, JSON is just right for this one. -Tim]”
(Via ongoing.)
After reading Tim’s post, I went directly to the Cloud API project site on Kenai and read all the docs for the API specification. Reading the specs raised some questions, most of which others were already discussing in the forums. I’m really digging the RESTful HTTP with JSON APIs. It just feels more natural then the Amazon AWS APIs.
Sun is retaining the separation between the APIs and the implementations and encouraging other cloud providers to also implement their APIs. Potentially allowing a client to have interoperability between CSP (Cloud Service Providers). I feel similarly about CSPs adopting Sun’s Cloud APIs as I do with JavaScript libraries adopting the Sizzle JavaScript Selector Library; i.e. Amazon AWS should provide an implementation of Sun’s Cloud APIs, or someone should write an adapter.
While the Cloud APIs are still in-flux, they are defiantly on the right path here. Sun is listening to the community while taking the feedback seriously; great to see from a big company with their open source project. Sun is stepping up the game by providing not just cloud-based resources, but an API built on current technologies (RESTful HTTP and JSON) and allowing any cloud-based service provider to use it.