PART III
Chapter 10: Web Services and Beyond 529
with a crossdomain.xml file, as we saw in this chapter. Someday, with native XHR support
for cross-domain calls, the domain restriction will fall away as we begin to provide multiple
DNS entries for our servers, but for now this too is a limitation we must address as well.
The solution to the Comet scale problem comes in two major flavors. The first option is
to move to a server-application programming environment architecture pairing that might
be more suitable to event-driven long-connection-style coding. One popular platform for
this is the Twisted (http://twistedmatrix.com) event-driven networking engine, which is
written in Python. The other solution is to use a helper server to offload the long-lived
connections but continue to employ the primary environment for normal pages. This is
similar to the approach we took in the binary bridge solution using a socket connection.
There is no doubt you can make a push-style application work, but as of yet there is no
optimal solution that most agree upon. Those who wish to explore this pattern once again
heed the simple warning that as of today, push-style applications will work well in the
small but not in the large without some careful planning or even architectural changes.Going Offl ine
The final frontier of Web applications using Ajax is going offline. If you could use a Web
application on the desktop when you are disconnected from the Internet, say as you fly
cross country, and then could later go back online seamlessly, there really is little difference
between a desktop application and a Web application. As of late, there's been a bit of envy
from Web applications of the desktop richness of offline capabilities, but on the reverse we
see desktop apps smarting from the difficulty of distribution and updates that Web
applications enjoy. Of course, software applications today rely on the Web to fetch updates
and patches to grab this benefit of the network-connected world. It’s only fair then that a
Web application looks to set up camp on a user's desktop.
What does going offline mean for an Ajax application? What changes will we have to
make? First, we need to persist data on the client and rebuild any application state from the
persisted data. In the last chapter, we alluded to having such functionality and performed
this task in support of history and back button concerns, so we’ll start with that. Second, we
will need to store resources offline. That might be a bit trickier, and without bleeding edge
browsers or extensions like Google Gears, we are out of luck. Finally, we will have to make
sure we can work without the network, which will certainly require some careful thinking,
interface changes, and extensions like Google Gears. So fasten your seat belts: this last part
will get a bit bumpy, but it is well worth the ride.Client Persistence and Storage
Even if we are always online, we will likely want to persist data between sessions or pages.
If this is performed client side, we nearly always turn to cookies. In Chapter 9 we saw that,
in support of fixing history and the user’s perception of a broken back button, we needed to
persist information to make requests or even the responses from previously sent requests.
We abstracted the persistence of data away from readers with the library, but here we reveal
some of the techniques that can be utilized to persist data. As with many things on the Web,
there are many ways to perform the same task, but we stick with the more common
solutions to the problem here.