My 2 cents on keeping states across multiple browser tabs:
* Having a single session across all tabs seems like most ideal way.
Else with N open tabs, BOSH connection manager should be ready to take
additional loads (which they anyways do right now).
* Map a single BOSH session to the entire browser session (not a single
tab), Multiple tabs simply become pipes/channels to this single session
* To save on client to server requests (specially in long-polling
mode), pause the channel on inactive tabs
* When user switches tab, current active tab channel gets resumed,
connection manager pushes unseen packets to current active tab (i.e. activity
which happened while user was active on other tabs)
* Connection manager can simply use reference of rid of channel
pause/resume request to calculate unseen packets to current active tab.
Ofcourse with this strategy, connection manager will need to buffer more
request-responses at it's end
* I strongly believe that pause/resume strategy is the ideal way to go,
since with 1000+ contacts in my xmpp account and the kind of presence storm my
account sees from google servers, if browser starts to receive all of that
across N tabs, it will either hang/crash/who-knows-what-else.
* Also from connection manager point of view, only one xmpp stream will
need to be opened to destination jabber server
We are using a similar strategy in production for a year now without any issues.
Will be nice to see something on similar lines becoming part of the official
spec.
--
Abhinav Singh,
Bangalore, India.
http://abhinavsingh.com
________________________________
From: Matthew Miller <[email protected]>
To: Bidirectional Streams Over Synchronous HTTP <[email protected]>
Sent: Friday, October 19, 2012 9:50 PM
Subject: Re: [BOSH] [Summit] BOSH discussion at Summit 12
On Oct 19, 2012, at 09:52, Jack Moffitt <[email protected]> wrote:
>> * 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.
>
> Yes we care about state. For example, the roster state. That is not
> easily recreated by another tab, and can be quite large. It's very
> expensive to re-probe it again, especially as page transitions can be
> pretty transient.
>
> Sure, some stuff can be punted to other methods, but I feel that there
> is something we can do to make this better rather than the user having
> to do everything by hand. For comparison, most similar pubsub systems
> not using XMPP do not share this problem because they don't have this
> notion of independent sessions.
>
> Failing to address use cases like this will hamper adoption of XMPP
> for web applications. People will just roll their own with tools that
> have more leverage.
>
I've found Local Storage APIs to be sufficient for page-to-page persistence,
and can see how it would help for multi-tab/window scenarios.
However, there is still the problem of many connections to the server, and the
various browsers have different limits as to how many of those are allowed at
any given time. Finding a way to share a single connection to the server would
be ideal, if one can find a way to not increase the security risks of
cross-sandbox sharing.
Even better is if the browser itself implemented XMPP ...
>
>> * 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.
>
> Sounds like my Shared BOSH proposal.
>
Carbons and MAM can also deal with the conversation log well, with the benefit
that it also applies to any other sessions the user has (dedicated desktop
client, mobile client, etc).
>> * 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 shared bosh type solution will probably have to have some plugable
> state knowledge for things like rosters. It would be great if it could
> keep that state so that clients could request it cheaply. I suppose
> one could do this in the session manager as well on the server side.
>
Again, I think Local Storage APIs help significantly here client-side.
>> * 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(?).
>
> Is there some benefit to identiying them? I figured the client can
> worry about its identification if it cares, and the developer can
> worry about that if they need client-to-client direct communication. I
> don't think it's a common use case that we need to handle in the
> sharing layer. You can already send messages to yourself, so it's
> only micro-self-distribution that it would help right?
>
I can see *some* need for these "sub-clients" to be aware of each other. For
instance, if the application utilizes the Web Notification API and I have three
windows/tabs for that application open, I really don't want three pop-ups (or
three vibrates, or three rings, etc), and I want none if I have one of those
windows/tabs focused.
Sure, this *could* be addressed with an application-specific inter-process
model, but if we're going to go down the shared session rabbit hole, we ought
to go all the way down that hole.
>> 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.
>
> How did the clietn interact with HTTP with your implementation? Could
> they see packets sent to other connections, etc?
>
> jack.
- m&m
Matthew A. Miller
<http://goo.gl/LK55L>
