Hi, 2009/10/28 Peter Saint-Andre <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/28/09 9:58 AM, Kirk Bateman wrote: >> Time to wade in with my comment :) >> >> Tuomas's point about specifically requesting new posts on login rather >> than expecting the node to start throwing back the missed posts while we >> were offline is actually useful, it means that you can delay the >> possible flood of posts. So for example if a user is subscribed to 20 >> nodes in the manner described when he logs in he can get the latest >> posts in a "controlled" manner (thus avoiding the normal presence style >> flood on login). At least thats my thoughts on what he said.
This is what I tried to explain. It seems my writing skills needs to evolve :-D 2009/10/28 Peter Saint-Andre <[email protected]>: > Yes, those are really two different models. The idea behind > presence-based delivery is that it is similar to presence itself -- I > don't need to specifically request presence from each of my buddies, > instead when I log in I start receiving interesting information. The > extended presence model used in PEP (which is the basis for all of the > presence-based delivery stuff) follows a similar model. For more > structured interactions, the model you suggest makes more sense. Yes. I will have the need for these both models: When the client is online, it will receive messages "real time" (presence_based_delivery), BUT the client must be also able (when needed) to fetch items from the node that were published when the client was offline. Because of this use case, I need to send the "<items> IQ-query" stanza as I described earlier. Does it make more sense now? Cheers, -- tuomas
