On Wed, May 30, 2012 at 5:49 AM, Lance Stout <[email protected]> wrote: >> I suppose there is nothing stopping you from subscribing directly to a >> components presence. > > Right, components can do everything a client can do, including sending > presence and handling presence subscriptions (after all, that's part of what > makes gateways work). The distinction, aside from the extra control over > JIDs, is that the server will not maintain the roster for you, so if you want > or need one you have to implement and maintain it yourself in the component. > The roster in the end is just a table of subscription mappings. > >> I haven't tried this as I have been relying on OpenFire. The OpenFire gui >> doesn't provide the means to setup a roster for a component. I will need to >> try to subscribe to it directly and see how that works > > > Again, that is because you would need to implement that inside your > component. Technically you could even hook into the server's roster storage > if it lends itself easily to the task, but it still requires that the > component manages the integration. > > Another difference is that you will probably also want to do presence probing > to receive initial presence updates, which is another thing that the server > does on behalf of clients that it does not do for components. > > For all of these reasons, in SleekXMPP we ended up adding a complete > multi-JID roster backend so components could easily have their own rosters. > > The only gotcha I've encountered with component presence and current server > implementations is that if the component crashes or goes offline, the server > will not broadcast unavailable presence like with clients. That can leave > contacts' views of the component's presence in odd states. The solution for > that, of course, is to have clustering, etc so that it doesn't matter.
There's also that if what you need is a JID that has rosters, server-managed presence, etc., what you're describing is really a client. Many uses of components could just as well be served by writing a client. Not all, by any stretch, but components shouldn't be the automatic go-to for writing a service. /K
