Thanks very much for your answer. I thought for a long time about an
answer and I have some things to say but I understood that all this
conversation is unnecessary till we don't have an answer how "from"
subscription should work with simple presence. I described the problem
in neighborhood thread and I had an experiment that proves that such
subscriptions don't work well on the ejabberd's example. Could you say
me where am I wrong and if that problem is in ejabberd and not in the
protocol itself? Maybe you know which server should I test to give well
results? I learned the RFC but I can't find the answer there. Examples
are too simple in it and don't cover such complex cases.
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.
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).
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).
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.
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.
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.
So while the advantages you state are pretty clear, I don't see a way
around the problems.
Dave.
