Pushlets & Streamlets

JMS1.1 provider ActiveMQ prefers the Streamlet approach(a web streaming mechanism) for a couple of reasons:

1.using Streamlets means that we use a distinct HTTP request for each send/receive which is much more friendly to web infrastructure (firewalls, proxies, caches and so forth) rather than having an infinitely-long GET.

2.can still take advantage of HTTP 1.1 keep-alive sockets and pipeline processing to gain the efficiency of a single socket used for communication between the client and server side; though in a way that works with any HTTP-capable infrastructure

3.the server is pure REST and so will work with any client side (rather than being tied to custom JavaScript function calls used on the page which the Pushlet approach requires). So Pushlets tie the server to the web page; with streamlets we can have a generic service which works with any page.

4.the client can be in control over frequency of polling & timeouts. e.g. it can avoid the memory issues of Pushlets in some browsers by using a 20-second timeout HTTP GET. Or using a zero timeout GET to poll queues.

5.its easier to take full advantage of HTTP encoding of messages, rather than using JavaScript function calls as the transfer protocol.

6.pushlets assume the server knows what functions are used on the client side as the server basically writes JavaScript function calls down the scoket - it's better for us to send generic XML packets (or strings or whatever the message format is) and let the JavaScript client side be totally decoupled from the server side

7.streamlets support clean XML support allowing full XML documents to be streamed to the client for rich messages which are easy to process via standard JavaScript DOM support