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
outlined.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
