Thanks for the comment/feedback Jack. I understand how the whole vision will change once we have web workers available. But i am sure, before we can start building something purely based on web workers, it will take some time. Just like websockets, they are there, but i don't really like to tie my implementations with their availability (atleast not as of now).
Idea behind the workflow i mentioned was to have separate channels forked out of the same bosh session (tabid can be seen as channel id). All tabs can continue sending/receiving data from bosh CM without caring about other tabs and their existence. Synchronization between tabs was achieved using trivial cookie based approach and most of the heavy work was done by bosh connection manager itself. EBosh CM wasn't echoing things back to every tab on the fly, but tabs were sync'd only when they become active. While a tab is inactive, nothing much was done by clients as far as synchronization is concerned. Haven said that, i do understand my implementation was more specific to the application, and i wasn't really pushing for a standardized way of doing this back then. I assume somewhere someone has already solved this (may be in a more standardized way) with current existing options. Probably, if the community thinks and if this really has to be a part of bosh spec (i don't see this point on bosh issues list webpage), we can work on a standard way for doing this minus web workers. -- Abhinav Singh, Bangalore, India. http://abhinavsingh.com ________________________________ From: Jack Moffitt <[email protected]> To: Abhinav Singh <[email protected]>; Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Friday, August 24, 2012 4:47 AM Subject: Re: [BOSH] issues list > 1) a bosh session was issued per browser session and not per opened tab i.e. > a single "sid" across all open tabs > 2) when bosh session is first issued, an attribute named "tabid" is also > provided to the connecting browse tab. > client will use this "tabid" (issued by the bosh CM) along with "rid" > for all bosh requests > 3) when a new tab opens up, client connects to existing bosh session for the > current browser session, > server simply issues a new "tabid", every open tab have their own > sequence of "rid" This doesn't help you much because without knowledge about what the other tabs are doing, there's no way to maintain state across tabs. The shared bosh stuff that I proposed had a way to subscribe to the traffic of the your shared peers so that you could make state changes based on what they were doing. I suppose you could echo everything each tab sends, but that might get unwieldy. The real solution is to use shared web workers, but sadly, these aren't well supported (if at all) yet. Then you'd have a central worker maintaining all the state and bosh connection stuff, and all the tabs would just communicate with it. jack.
