|André Warnier||Jul 3, 2013 9:38 am|
|Jess Holle||Jul 3, 2013 10:57 am|
|André Warnier||Jul 4, 2013 2:17 am|
|Martin Grigorov||Jul 4, 2013 2:22 am|
|Mark Thomas||Jul 4, 2013 2:30 am|
|André Warnier||Jul 4, 2013 7:52 am|
|Martin Grigorov||Jul 4, 2013 8:04 am|
|Mark Thomas||Jul 4, 2013 8:11 am|
|Pierre Goupil||Jul 4, 2013 10:43 am|
|Howard W. Smith, Jr.||Jul 4, 2013 12:22 pm|
|André Warnier||Jul 5, 2013 12:39 am|
|Howard W. Smith, Jr.||Jul 5, 2013 4:56 am|
|Rossen Stoyanchev||Jul 8, 2013 6:07 am|
|From:||André Warnier (aw...@ice-sa.com)|
|Date:||Jul 3, 2013 9:38:42 am|
I am looking for general and not so general info about websockets.
I have read the Wikipedia article, RFC 6455, the websocket API doc on MSDN, and
pretty much all that I have been able to find on the WWW. But I am still not sure if I have a full picture.
This is the context : we are currently developing an application in which a
client (initially, a user with a browser) enters a search expression and submits it to the server, for the server application to execute against a
number of "information providers" (say Google Scholar, Pubmed and Amazon). The application on the server then, connects in parallel to these information
providers, submits the search to each, and starts collecting results (list of articles or
books e.g.). These results "trickle in" from the various sources, at different rates. The client is impatient, so it would be of benefit to start showing results in
the browser as soon as some are available (on the server), and keep updating his display
after that with whatever arrives from each source, more or less as it arrives. Typically, such an "update" from the server would be from 20 to 50 "references"
(title, authors, etc.), so basically text, probably sent to the browser in JSON format.
One "classic" way for us to implement this, would be by doing some kind of
regular polling from the browser side, to ask if there is any update available. This is technically easy via AJAX techniques, but it requires quite a bit of
machinery on the server side (sessions, long-running processes to reconnect to etc.), and is
not very efficient.
We were thus thinking that this might be a good case for implementation through
a websockets connection, even though the needs are not as "real-time" as a game or
a chat-like application for instance. And of course for our team of young
developers, it would be rather attractive to be using some real cutting-edge technology..
However, from all my current perusing, it does seem to me that websockets is
still not really "production-ready" (I am not talking about the Tomcat implementation per
se, but more generally). For example, I could find a discussion thread from back in
March this year (http://www.gossamer-threads.com/lists/apache/dev/423880), in which it
seems that an Apache httpd proxy module for websockets is just in its infancy at the moment. There is also the fact that native websockets capability in IE is only available
since IE-10, and that solutions which allow this to work in lower IE versions are a
bit "iffy" (relying on a diversion through Adobe's FlashPlayer e.g.). (Most of our customers are largish corporations, which are not going to update
their browsers, nor open special ports in their firewalls, just to please us).
So, in short - so to speak - does anyone have comments to contribute about this