-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 2:40 PM, Peter Saint-Andre wrote: > On 10/28/09 11:32 AM, Tuomas Koski wrote: >> 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? > > Yes, it does. I'll look at this more closely during my next round of > edits, which needs to happen by the end of next week because then I > travel to Japan for IETF 76.
I still think we could handle this using XEP-0256: <presence from='[email protected]/balcony'> <query xmlns='jabber:iq:last' seconds='86511'/> </presence> Then the pubsub service sends you everything that has changed in the last 86511 seconds (or thereabouts -- perhaps it sends you things a bit older than that to handle clock skew and whatnot). However, if you need more precision then we can look into add a 'ver' attribute with the same semantics as roster versioning (see XEP-0237). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr2k60ACgkQNL8k5A2w/vyJmwCg25bVCAozWeP8DUC1zzAm+w6v jBYAoLipl1zmgqtfXUBVswXXAY5Af2ra =1rUr -----END PGP SIGNATURE-----
