On 12/15/2011 01:05 AM, Dave Cridland wrote: > On Wed Dec 14 16:54:55 2011, Sergey Dobrov wrote: >> On 12/14/2011 10:39 PM, Dave Cridland wrote: >> > On Wed Dec 14 12:51:22 2011, Sergey Dobrov wrote: >> >> On 12/14/2011 07:19 PM, Dave Cridland wrote: >> >> > On Wed Dec 14 11:53:50 2011, Sergey Dobrov wrote: >> >> > >> >> > You can query the PEP service and it'll tell you the subscribed >> nodes, >> >> > so you only need to store the services - in your described scenario >> >> > these services would be stored in your roster, which is convenient. >> >> >> >> Store services in the roster instead of users? I think it's >> ridiculous. >> > >> > Your scenario is that the client has a one-way subscription to a >> contact >> > and you want PEP stuff from this contact. >> > >> > Therefore, the contact is in your roster. >> >> Yes, and I am receiving events on the end that doesn't have to receive >> them! Very useful! >> >> > I have no idea what you mean. You did say you had a subscription to (but > not from) the contact you wanted PEP stuff from. So that contact will be > in both rosters already. You can then list the manual subscriptions, get > any items you've missed, and so on. It does mean doing manually what'll > happen automatically with a subscription of "both", but that's the penalty. >
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... > >> > >> > The PEP service jid is the same as the contact's jid. >> > >> > Therefore, the PEP service is stored in your roster. >> > >> > Therefore, you are already being as ridiculous as is required. >> >> Yeah. But you are missing all convenience and integrated approach of >> xmpp. I can make some workarounds if I will get things work right in the >> future. But I think that if we will not notice such fundamental problems >> now then we will not be able to solve them in future because we will >> have more and more underlying things. I understand that I, maybe, ask >> for some ambiguous things and ask too many things. But the situation is: >> I fight with juick.com that it doesn't follow XMPP standards at all, it >> doesn't want to find a ways to make things well support RFCs and XEPs. >> Then I start to work on my own project that will follow these things and >> I see that standards are not ready to use in real life projects. I >> propose ways to solve these problems but I see that nobody wants to >> solve them. I don't insist that my ways are ideal but I propose >> something, at least. So it seems that I am completely lose: juick works >> but mine implementation can't do such simple thing as user subscription. >> But if we will look deeper: maybe it's a loss of XMPP itself? > > But the standards you're talking about work in real-life projects just > fine. I don't know how many people routinely use PEP, but the figures > are hardly small. > > What you're after is a presence-based subscription without having > presence, and that's bound to be problematic. Any way of avoiding a > bidirectional presence susbcription being involved is going to cause > other compromises to be made - these compromises may not matter to you, > but they certainly matter to others, and they're reductions against > what's possible now, so need a tremendous advantage to outweigh them. > > 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. 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). 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. > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
