[Standards] PEP inconsistency with presence subscription

Dave Cridland dave at cridland.net
Wed Dec 14 11:45:30 UTC 2011

On Wed Dec 14 09:23:08 2011, Sergey Dobrov wrote:
> 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.

I offered a strawman solution to your stated problem, and described  
why I thought that it was infeasable. So I don't think the problem  
can be solved. Would it be nice to solve? Maybe. Not on my list of  
critical problems, though.

There are, I think, a multitude of cases where XMPP essentially  
relies on two-way subscriptions, I don't think this is a problem we  
can solve at this stage.

> 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.

OK, so that's perfectly reasonable, but also you can't change those  
properties without effectively having a manual subscription anyway.  
Manual subscriptions bypass your stated problem. I also suspect  
they're incompatible with my strawman design.

> 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.
I think you're describing a possible implementation, but it makes no  
difference to the outcome - the data, whether or not it is to be  
used, will still need to be stored, irrespective of whether you try  
to unify storage facilities.

> >
> > 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.
Retractions currently need not be broadcast; I don't think this is a  
fatal flaw, by any means, but I noted it as a part of the changes  
required, and it's a further example of the kinds of the impact that  
are forced on PEP by these changes.

> >
> > 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?
I think you're seeing PEP as a cut-down PubSub service; it's not. It  
has a relatively small number of mandatory features, a mandatory set  
of defaults, and it can be limited to those - however it needn't be.  
Using collections, manual susbcriptions, and other XEP-0060 features  
on PEP nodes and sevrices seems like a fine idea to me with many  
interesting use-cases. I don't know why you'd want to prevent these.

> 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 have no idea what you may be implying here. One implementation may  
indeed store offline messages (and, following on from your previous  
suggestion, PEP items) in a database or similar disk-based storage,  
but that's an implementation detail. In any event, this will be a  
markedly higher level of storage than for offline messages; in  
particular we can assume that each contact will be generating  
multiple items due to multiple active PEP nodes. I just don't see why  
this would not incur a performance impact.

> > Finally, it also breaks if PEP nodes have a non-uniform ACL, of  
> course.
> What do you mean?
I mean it also breaks if PEP nodes differ in their configuration, in  
the general sense, and particularly if they differ with respect to  
access control.

PEP nodes have a default configuration, but some clients can,  
already, change the configuration of particular nodes, and it's  
really not clear how this would effect the strawman design I've  

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list