On 12/16/2011 01:02 AM, Dave Cridland wrote: > On Thu Dec 15 12:54:28 2011, Sergey Dobrov wrote: >> I meant that if I have a contact in my roster with "from" subscription >> then I will receive it's events but I don't want to receive them because >> I did not request it's subscription. I have to filter them additional on >> client side? Strange way... >> >> > If you have a subscription 'from', then you won't receive any PEP or > presence.
I am receiving them when from subscription. I will never say before check. > > If you have a subscription 'to', then you don't have PEP events, because > those are presence based (and you're not sending presence). But you can > use these to handle the item retrieval and maintain manual subscriptions. > And will increase traffic for clients which don't support microblogging. The PEP protocol is again loss. The things that it was designed for are work well only for very simple protocols like moods. >> > Maybe if you can explain precisely what your use-case is, then people >> > can provide you with explanations of how to achieve it with what we >> have >> > - and if not, then we can figure out what needs to be done. >> >> Ok, the task is easy: I have microblogging service based on some subset >> of XEP-277. To subscribe to the user's blog I request user's >> subscription. My client will automatically accept any subscription >> request to allow any user to read it's blog. User will see a notify that >> someone subscribed to him and probably will subscribe too. But if user >> will not subscribe, he will have reversed behavior: he will receive blog >> entries but user who subscribed to him will not. It's very useful to use >> regular subscriptions for that case because I don't need to maintain the >> list of subscriptions, I can use roster in regular way: to chat and see >> statuses, I can allow clients to use regular jabber clients to use them >> accounts to chat. Many many benefits here. But if I will maintain PEP >> subscriptions separately then user will be able to remove any contact >> using regular jabber client but it will not remove pubsub subscription >> to it's blog and then there will be a real hell and desynchronize. >> >> > Actually no - if the access-model of the node is set to presence (as is > the default), then the manual subscription ought to be removed when the > user unsubscribes from the contact. > Ok, will check that. > >> I already told that most XEPs based on PEP now are just extended >> statuses (moods/activity,something) and it's really strange when user >> have a contact with "to" subscription but can't see it's mood or >> something. I understand that it's not often case when regular jabber >> user have "to" subscription (but I have many such contacts, for example) >> but I think that such thing may be a really big problem for some >> applications (like mine). >> >> > It's presence-based susbcription. You're only subscribed when you send > the presence, in effect. > > >> About compromises. I think that we have to discuss them. I did not hear >> any thing that is impossible to solve yet. But I know, for example, that >> jabber.ru implementation of PEP don't filter any PEP messages at all! >> Because of lot memory consumption. So I see that PEP is not work too >> good as it seems in real life. > > I would note there are plenty of implementations that filter properly, > so I wouldn't say it's an impossible thing to do. Some of these run > quite big deployments. May I ask about examples of such software and deployments? I am worrying about high load too. Also, I wanted to ask about big solutions which uses PEP/Pubsub in real life applications to learn how them work. > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
