> * 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. > * 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. > * 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. > * 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? > 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.
