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>
smime.p7s
Description: S/MIME cryptographic signature
