On Wed Apr 6 19:55:17 2011, Waqas Hussain wrote:
Also, PEP in MUC is not a solved problem. I do like avatars in MUC.
I'd note that in Belgium, the consensus seemed to be to solve that
problem rather than continue to work around it. Additionally, a
recall the consensus as being to deprecate vcard4-for-avatars in
favour of XEP-0084.
All that said, I would really really love to have a generic
framework
to do for PEP and pubsub and disco and everything what we currently
do
for avatars via hash in presence. We added hashes in presence to
avoid
iq:avatar, iq:disco and iq:version floods on login. When we start
having large data in PEP/PubSub, PEP floods are going to become a
serious problem.
One obvious solution is a 'hashes' node in PEP. You subscribe to
that,
and you get hash updates. A hash update is a set of hashes for
avatar,
versions, custom namespace, etc. You send a manual request for what
you want to actually get, and cache the result for the future. It
would be nice to have this also requestable via IQ (possibly a
pubsub
IQ).
Perhaps a subscription option?
We treat PEP's auto-subscribe from the bare jid, plus filtered
notifications, as an auto-subscribe from each full-jid, incidentally,
which makes this easier (if semantically wrong), but if these
subscriptions could (by dint of an additional disco#info feature
advertised via caps) indicate that a they only wishes to receive a
hash of the last item on subscribe, that might work.
But I suspect it places us into a canonicalization trap, and in any
case it will increase, not decrease, the number of stanzas.
Alternatives are to send a timestamp with initial presence - possibly
managed by the server on a per contact basis to mitigate the privacy
issues.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
