so nice to see a point raised on standardizing specs for "cross tab sessions" in the past i have had my attempt to achieve this and had a fair success my implementation assumed following philosophies and workflows:
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" a custom bosh connection manager implementation was required, which used to deal with holding and release of client http requests per "tabid". many might not find this as standard approach, but mixing the above workflow with trivial cookie based synchronization for new open tabs and binding http bosh session with web application session, provided a stable, secure and not so complex approach to get "cross tab sessions" or "facebook-like chat" going. i wasn't pushing for any standards back then but focus was to get this done securely and without much added complexity inside my web application. i recently open sourced a part of that custom bosh connection manager here (https://github.com/abhinavsingh/ebosh). Open sourced version still doesn't have the above workflow. though i am not too sure what a standard way of doing this would be, i will be interested if others who might have achieved this already can throw more insight on the above workflow. if found suitable, i can dig back into the exact implementations i did (way back in early 2011) to keep everything sync'd/sane/secure across multiple tabs on the browser. -- Abhinav Singh, Bangalore, India. http://abhinavsingh.com ________________________________ From: Waqas Hussain <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Thursday, August 9, 2012 11:37 AM Subject: Re: [BOSH] issues list On Thu, Aug 9, 2012 at 8:05 AM, Jack Moffitt <[email protected]> wrote: >> Right - but that is mainly discussing an out-of-band HTTP request with >> a custom non-standard payload. Standardizing such a payload wouldn't >> be 'informational' but clearly a protocol. On the other hand if it >> doesn't specify *how* to do it then it seems little more than a note >> to say "You can do this!" - which seems like if necessary it could >> live in the BOSH XEP itself just as easily. > > I would like to specify the how as a protocol we can all agree on. The > fact that there are 4-5 implementations all slightly different is a > bit annoying. This could easily be done by the BOSH servers themselves > with just a little bit of added protocol. > > Also, we should add initial data examples to the spec since that > appears to be a big win and is far less complicated than pre-binding. > > jack. > > PS. What are Carbons + MAM? XEP-0280: Message Carbons XEP-0313: Message Archive Management Carbons allows replicating outgoing+incoming messages to all carbons-enabled resources of a user. MAM allows retrieving conversation history. These two combined with some extra bits allow conversations that survive on multiple tabs, through reloads and navigations, and even across websites. In the mentioned private client we fully inline these in the first BOSH request, and the client gets everything it needs on the first response. Cross-tab sessions by the way are the largest missing piece of the BOSH puzzle. It's a wide gaping hole, and we keep getting requests regarding "facebook-like chat". As far as I know, the XMPP community has no spec, no public code, not even any tutorials, blog posts or useful discussions on the topic. I would really like to see this solved. I'm certain BOSH would become a lot more attractive to the wider web developer community if we do. -- Waqas Hussain
