Re: [xmpp] multi-tabs (was: Re: Consensus Call : Adoption of draft-moffitt-xmpp-over-websocket)

[Lance Stout <[e-mail]>]

> > If are talking about websockets, how are you dealing with multiple
> > tabs opened by the user?
> 
> That's a difficult issue and it probably isn't even something we can
> solve in the XMPP Over WebSocket specification. But discussion is
> welcome (I've branched off a new thread for that purpose).


Right, any solution for this problem would likely be applicable across
all "* over WebSocket" use cases.


Having implemented XMPP over WebSockets in the browser, here's what I've
learned so far:


1. Ignoring tabs at the moment, just navigating to a new page can be
   handled very quickly using Stream Management (XEP-0198) resumption
   if the ack data is preserved in something like localStorage.

2. Not giving special consideration to tab connections works remarkably
   well when using  MAM (XEP-0313) and Message Carbons (XEP-0280). The only 
   downside is that you have to do the entire stream startup unlike when
   doing session resumption. So the full
   
      a) auth
      b) bind
      c) roster (skippable if you use roster versioning)
      d) inbound presence
      e) inbound pep

   That said, if you are caching data locally for the origin domain (using
   IndexedDB, etc), then you can use that to bootstrap the UI while the
   initial data streams in, much like you would for session resumption.

3. If you really don't want a new connection per tab, things are very 
   tricky at the moment. Running a WebSocket connection as a Shared Web
   Worker process doesn't appear to work, nor can a shared worker access
   the DOM methods needed to parse XML.

   But you can use them or window.postMessage to broadcast information from
   the tab that has the XMPP connection to other tabs. Of course if the tab
   with the connection is closed, things get fun very quickly :)



-- Lance