Am 19.10.2012 um 04:27 schrieb Jack Moffitt <[email protected]>: >> Winfried and all, could you please suggest specfic topics for the BOSH >> discussion? I'd like to make sure we cover what's important. So far I >> have BOSH vs. WebSocket (performance, migration, etc.), comments on the >> Internet-Draft [1], and fallback scenarios. What else? > > The main one in my opinion is to discuss what to do about keeping > state across tabs and page loads. I'm not sure Shared-Bosh is the > solution, but this is the #1 problem from Strophe.js users.
As well as for JSJaC users ;) Some notes on this topic: * Do we really want to care about "state" in this context? At least if state means the state of the actual client. Like which chatbox is active/open at some given time and so on. I'd say this is outside the scope of XMPP whatsoever. Clients can serialize their state to some DB of their choice and recreate their state from there. Of course the DB can also be addressed by sth like jabber:iq:private. * Sharing a connection could be done at some intermediary level that sits between BOSH or Websockets on the one side and the actual server on the other side. Such a thing could be seen as a multiplexing proxy that holds a connection for a client, stores incoming stanzas as required and forwards them to connecting clients. Business logic could be like: When there is a new incoming connection (doesn't need to be an XML stream - could think of HTTP requests as well) check if this user (see below) already has an active session, if so, discard creating a new stream and reuse the existing one. If not, create a new one. * It also should bounce messages sent by a client to all other clients so that chat histories all look the same. * Rosters could be recreated by such an instance if the proxy caches incoming presence stanzas and forwards them the new clients connecting as soon as they send initial presence * The main problem to solve here (as with the Shared BOSH proposal) is how to identify the clients at some level outside the XMPP stream(?). As a remark I've implemented sth like that already but in that case authentication was a no brainer as this was handled by an pre-existing HTTP based service that sat in front of the BOSH service. .Steve
