On 12/14/2011 06:32 PM, Kevin Smith wrote: > 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.
I don't understand why to do that. It can store just the last one to store it in it's offline storage. I don't see an overhead here, servers store offline messages for long time ago. > * 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. It doesn't need to know anything about ACLs. Sender will just send to bare JIDs, only for allowed JIDs. > * [Not an impossible failing but heavily undesirable] This generates > something of a bandwidth explosion. I not agree. I think that it will decrease a bandwith, at least S2S since we have not to send each event to each resource, we have not to send last item through S2S each time new resource connected. > > 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. For example? Obviously, I can subscribe to nodes directly but where to store the list of subscribed nodes? I think that this problem must be definitely solved since it breaks a PEP idea at all. > > /K > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
