On 10/20/2011 03:43 PM, Dave Cridland wrote: > On Thu Oct 20 09:19:06 2011, Sergey Dobrov wrote: >> On 10/20/2011 03:56 AM, Dave Cridland wrote: >> > a) Probes are sent from the bare jid. >> > >> > b) Probes don't have an unavailable equivalent, needed to later remove >> > the subscription. >> How this solved for regular presences? >> >> > You get a later type='unavailable', which causes the PEP subscription to > go away (technically, for the PEP subscription filter to be disabled). > No, I meant the case when subscription is "to". A server sends "probe" presence, then we receive remote user status. How remote server can know that it can stop to send presences?
> >> > >> > c) Probes don't have the caps inside. >> > >> > For PEP to work, the PEP service needs to know all three of those, so >> > basically it needs your presence - or a functional equivalent of it. >> I see the problem only in the "a" case. So the only way to solve that is >> to send iq subscriptions by user's server? >> >> > What you need is for the PEP service to know when you're online, and > know when you go offline. It also needs to know the caps of the client > that's involved. > > This is all done by presence, in XMPP. > > If you do it as an <iq/> based filtered subscription as Joe proposed, > then you still give out the same information, you're just no longer > calling it presence. I think that's actually more dangerous, because > it's slipping the same information by the back door and is very likely > to end up causing unpleasant surprises. > > If you want a fixed subscription - that is, you want the events sent to > you whever the owner posts a message, whether or not you're online, etc > - then the existing subscription mechanism works fine. The problem with that is that we will have two desynchronized rosters. For example, I use two clients, the first supports PEP and the second doesn't. I subscribe to some user via the second client and then the client subscribes to it's PEPs, then I will receive extra traffic on the first client even when I can't use that and if I unsubscribed from the use via the first client then I will receive that notification even when I have no subscription from the user. That things will make clients too complex. So I think that this problem must be solved on the server side and transparently for clients. > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
