This chapter describes the consequences of using Pushlets
As with any mechanism or design pattern there are obvious advantages and disadvantages with Pushlets as
compared to Java-based applet solutions that use messaging or client callbacks with CORBA/RMI.
direct integration with DHTML within the browser: data generated by the server can be immediately integrated into the
the page content of the browser. All the layout capabilities of HTML can be directly applied.
Unless the entire client is implemented in the applet, it is hard to integrate the applet with its containing
standard HTTP port and protocols: messaging and RMI/CORBA use non-standard ports which may not work through
firewalls, or browser security restrictions may prevent callbacks or receiving data over UDP.
client weight: Java applets with RMI/CORBA often make the client more heavyweight in startup and
no extra server: messaging and RMI/CORBA often require a dedicated server product to be maintained. Pushlets
can in theory run on any servlet engine, using its functionalities such as
connection management and multithreading (this may be disadvantage as well, see below).
small protocol overhead
cross-browser DHTML: effort is required to make cross-browser DHTML libraries that work in all browser versions
on all platforms.
scalability: When 100-'s of clients are connected
through Pushlets they may hog resources such as threads and sockets. On this type of scale it would be better
to serve Pushlets off a dedicated servlet server optimized for this type of usage. Scalability is also an issue
with CORBA callbacks.
webserver issues: a webserver is usually not designed for long-lived connections. A solution is the same as
applied with 'scalability'.
proxy-buffering: one reviewer pointed me at the fact that some proxy-servers may buffer HTTP data.