Peter,
Personally I'd prefer something more like muc's history with since and
maxstanzas attributes.
Using last on presence stanzas just seems wrong and more like a hack :)
Just my thoughts
Kirk
On 8 Nov 2009, at 09:47, Peter Saint-Andre <[email protected]> wrote:
-----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-----
