On Wed, Dec 14, 2011 at 9:23 AM, Sergey Dobrov <[email protected]> wrote: > On 12/09/2011 07:59 PM, Dave Cridland wrote: >> 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. > > Okay, it's obvious now that the main difference between regular > presences and PEPs is in filtering messages feature. I really don't see > more natural way to solve the problem instead of move filtering on > receiver's server. Any other way will mean a leak of user's presence. We > can allow it if we will think that servers will no transmit this > information to the clients but we can't be sure in it. Please tell me if > you think that it's ok to solve problem in the way of translate user's > caps to the other side like it was offered earlier.
Having the receiving server filter pubsub is not going to work for a number of reasons, including: * It needs to cache every (+notify) pubsub node, everywhere that any user of the server may ever see one. Storing what amounts to a local copy of all remote pubsub servers isn't viable. * The receiving server does not know what ACL should be being applied to the node items, so is not able to correctly distribute the items. * [Not an impossible failing but heavily undesirable] This generates something of a bandwidth explosion. If you want to be able to use pubsub without mutual presence subscriptions I suggest using one of the other subscription types instead of the presence-based +notify magic, which relies on presesence. /K
