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. I don't know if you agree with me that the problem must be solved. But I will think that you are by default because this conversation is senseless if not. If you are not agree please tell me, I will try to explain my point of view to the problem. Now, I will continue. > > 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). There is some other kind of problem I see in pubsub: I don't understand why properties like "send retract items" or "send last item" are in node's properties and not in the subscription properties. Since the necessity of these notifications depends on client needs. For example, if I have microblogging service and my client has a possibility to show new messages but have not a possibility to remove posts from a feed then, probably, I don't need to receive retracts for these nodes but I can't suppress them. So, I think that the problem can be solved by reusing server's offline storage. Server just will need to store some meta information for the message and then it can not remove some messages from it's spool when it sends the message and so it will resend the event each time user connected. > > 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). Since the filtering is not in a care of senders server I don't see the problem in it at all. > > 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. I can't imagine why it can be needed. Maybe you can give me a link with explanation or something? > > 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. The offline storage is saved on disk in database but caps cache is stored in memory to provide better performance. I don't think that the disk is a bottleneck for the present time. > > 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. What do you mean? > > So while the advantages you state are pretty clear, I don't see a way > around the problems. > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
