Martin Tyler wrote: > The use case mentioned, a number of widgets on a single page... if they > are talking to the same server I would think it is likely that they can > use a client side api to manage the multiplexing. If the widgets are > truly totally separate pieces of software written by different people > how likely is it that they will be talking to the same server? Consider google and who have the igoogle portal page which allows third party gadgets to be plugged into the page. They also have a WS API that those gadgets can currently make ajax requests to, when they do this, the gadgets share the connection pool from the browser to the google servers. If google started providing a comet API on their servers, then all of a sudden, these 3rd party gadgets would each be having their own connection and doing their own connection management. Note also, I don't think we can use the non-existence of a style of webapp today as evidence that it will not be done in the future. Perhaps they do not exist today because it is simply too hard to do - and that the existence of a better communications abstraction will make all sorts of new web applications possible. > Maybe we should go into more detail on the use case for > channels/multiplexing being built in? At the moment I cannot see the > scenario where a library on top of websocket couldnt do the job better How could a library on top of websocket enforce orgin based security? How could a library on top of websocket implement a connection sharing policy for a 3rd pary component written directly to the websocket API? regards
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.