Hi, Michael, Interesting use case.
On Tue, Sep 14, 2010 at 01:11, Michael Smyers <[email protected]> wrote: > I need to have my server talk directly with my clients. This "broadcasting" or "server push" scenario is where XMPP shines compared to HTTP. Please note that your clients need to actively connect to the server before the server can push messages to them. (If the server needs to connect to the clients, you'd need a more complicated and degenerated setup. You'd have XMPP servers on the clients and on the server n clients connecting to them.) I'd recommend that you have a dedicated user, which is pushing out the messages on behalf of the server, and which resides on the server. > I want to disable any client-to-client cross talk. Is this a possible use > case for XMPP? XMPProtocol takes privacy seriously, so: yes. > We need to be able to talk to any given user 2 ways: via session id and via > user name. > > So for example, my server might need to talk with their web browser via > session id 335, ... This is supported by XMPP. The session id is called "resource id" in XMPP, the user is addressed by a JID. Every client connects using a "pure" JID, eg. "[email protected]", but every client instance for the same pure JID is assigned a "full" JID, including resource, e.g. "[email protected]/cuzZjhef", where cuzZjhef is the resource ID string. I'd recommend consulting http://s.apache.org/xmpp3920bis13 The full JID makes the client addressable "by session". > ... or it might want to talk with "all of their connected devices" under user > id 25? Some types of messages are not distributed to every client, but some are, eg. "presence". > Is this a possible use case? yes, I think so. Some more thoughts on this: XMPP has a PubSub extension (XEP-0060), which might be a viable option for you. xmpp.org has a number of excellent mailing lists on XMPP, where the creme de la creme of XMPP community hang out. Have fun, Bernd
