On Mon, Sep 21, 2009 at 11:49 PM, Robin Collier <[email protected]>wrote:
> > I think you will see cases where both are valid (node and subscription), > depending on the context > in which the node is being used or the data it stores. I agree though that > the repercussions of not having it on the node can be pretty high in an > openly accessible system. You would obviously have > to put custom code in the server to 'fix' this problem in your case. > > Actually, I wrote a plugin for OpenFire to do the same thing for a project > I was working on. > > I think you could see the need for the subscription based approach as well > though. For example, > if a node was being used to publish notifications of news events, and the > node is configured to > publish when the user is not present, it would allow clients to determine > how they want to consume > the events. Where some may want all events, even when offline, others may > only want them > when online. This is a case where the node doesn't care how things are > being consumed, so the > onus is on the consumer to specify. > Agreed, there are valid use-cases for the subscription option as well. Both approaches should probably be standardized, as the node config option is a must. There are certain situations when temporary subscriptions are the only sane kind of subscription. More precisely, these are the situations where a part of the JID is randomly generated and therefore transient - so we can't expect this JID to ever appear again after going offline. One such situation is when using SASL ANONYMOUS. Another is when the client connects without specifying a resource - in this case some (all?) servers generate a random resource server-side.
