[Standards] PEP inconsistency with presence subscription
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
> 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
> 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
> needs. For example, if I have microblogging service and my client
> has a
> possibility to show new messages but have not a possibility to
> posts from a feed then, probably, I don't need to receive retracts
> 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
> storage. Server just will need to store some meta information for
> 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
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
> > out (ie, we must mandate notify-retract).
> Since the filtering is not in a care of senders server I don't see
> 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
> > more than just the last item on reconnect. This would mean
> > 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
> 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
> 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
> 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
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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards