On Fri Dec 9 12:18:14 2011, Sergey Dobrov wrote:
Guys, don't you think that it might be reasonable to filter
messages on
receiver's server side and not on sender's side. I understand that
it
will break compatibility and will no work if receiver's sender
doesn't
support PEP but it will be more efficiently because server will no
more
need to store all users capabilities, it can store only
capabilities of
it's own users. Also, events can be sent only once to bare jid and
not
to each full jid, etc.
OK, so let's assume that we want to try this:
1) First things first, we need to signal support for this. I suppose
this means that we need to do feature checks via disco for all the
subscribers - that is, when we receive a valid probe, we then need to
check the features of their server. Server-caps could help with this.
This removes one of the showstoppers you mention above.
2) We're also going to need to resend the last item when the
subscriber comes online. This is problematic for the node owner's
server, because receiving a probe doesn't actually indicate an online
event. The only alternative I see is that the subscriber's server
needs to store the last item for all the owner's nodes. Note, too,
that this needs to happen for all nodes, whether or not the
subscriber has ever needed the item (ie, whether or not the
subscriber is actually subscribed).
3) Finally, the subscriber's server will need to track retractions,
and all retractions made on the owner's server will need to send an
event out (ie, we must mandate notify-retract).
This covers us - just - for basic PEP. However, there have been
suggestions of using PEP in a more advanced way, for example sending
more than just the last item on reconnect. This would mean signalling
this back to the subscriber, and the subscriber's server maintaining
a shadow copy of all the items.
Some figures:
The incumbent protocol supports a caps cache which tends to be less
than the number of contacts total; but this caps cache can be used
for other things. (See my disco caching thing).
Your replacement looks to my eyes to have a caps cache, this time of
servers, which is likely to be markedly smaller. Hoorah, a saving.
But it also needs to maintain a cache of at least one item per PEP
node of the contacts, which seems very worrying.
I don't see this as an improvement, especially given the other
downsides you've previously highlighted.
You could mitigate this by discarding the send-last requirement, but
I don't think this is viable, and it's certainly less viable than
requiring either presence sharing or a manual subscription.
Finally, it also breaks if PEP nodes have a non-uniform ACL, of
course.
So while the advantages you state are pretty clear, I don't see a way
around the problems.
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
