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