HTML and CSS Reference
In-Depth Information
can use multiple strategies to implement a standard API. For example, Kaazing has a
polyfill for the WebSocket API that uses secret sauce streaming techniques and provides
a fallback solution for WebSocket applications running on browsers that do not support
WebSocket.
Modernizr, an open source project for HTML5 best practices, maintains a wiki
with an up-to-date list of polyfills and their descriptions for a wide array of HTML5
technologies, including WebSocket at https://github.com/Modernizr/Modernizr/
wiki/HTML5-Cross-Browser-Polyfills .
Different Abstraction Layers
There are other libraries like Socket.io that use WebSocket and Comet techniques to
expose a single API. Some of these libraries have APIs that are the same as the standard
WebSocket API, and therefore are polyfills. Other libraries include APIs that differ from
the WebSocket API, but use WebSocket as a transport strategy to provide a different
communication abstraction. This technique does not necessarily make them less optimal
than polyfills, but code written against standard interfaces is more portable and future
proof in anticipation of the day when fallback libraries are no longer necessary.
Even the best fallback implementations that employ Comet techniques have
their downsides. These are, essentially, the flipside of the benefits of using WebSocket
as a transport layer protocol in your applications. Emulation is essential for ensuring
connectivity with legacy browsers and over adverse networks, but it is important to know
what you are losing when you resort to a fallback strategy. Many of the reasons are what
compelled WebSocket to be developed in the first place. When choosing and designing
your fallback strategy, you may want to keep in mind that these emulation techniques:
Are Non-Standard: As we described in Chapter 1, these fallback
options are non-standard, which was one of the reasons
WebSocket was created. With these non-standard techniques,
different WebSocket emulation clients and servers cannot
communicate among themselves.
Provide Decreased Performance: High performance Comet
implementations can stream data in only one direction: from the
server to the browser. Even optimal WebSocket emulation over AJAX
implementations cannot stream data from browsers to servers.
Have Browser Connection Limits: Browsers restrict the number
of HTTP connections per host. Comet connections count against
this limit.
Have Complicated (or Non-Functional) Cross-Origin
Deployment: WebSocket has had origin security built in from day
one. Cross-origin AJAX requires additional configuration to work
with legacy browsers, when it works at all.
 
Search WWH ::




Custom Search