On 3/14/12 10:42 AM, "Sergey Dobrov" <[email protected]> wrote:
> On 03/14/2012 09:28 PM, Joe Hildebrand wrote: >> >> It could be used by non-PEP pubsub, by, for example, sending an ago stanza >> in your subscribe, or by translating it into a subscription option. > > Yeah, I just mean that it'd be cool to describe such way because it will > probably use iq and not presence. Sure. Let's add it. >> XEP-292. Both my vCard that you have subscribed to as well as my list of >> contacts. I don't want the client to have to receive all of these vCards >> every time they log in, including the base64 avatars. >> > > It seems to me that the XEP-292 needs from/to subscription states to be > processed correctly too. Because it will be strange for user that he can > maintain one-way subscription but he can only get vcard updates for > "both" subscribers... Maybe I am wrong, but I am persistently see an > inconsistency here. The XMPP Core protocols provide us the one way > subscriptions but it seems that them will be completely unuseful in the > near future because modern protocols forget about them. I see the > clients complication issues here too. Please make sure you've seen the contacts portion of XEP-292 as well: http://xmpp.org/extensions/xep-0292.html#contacts This part is about storing a list of contacts for *myself*, so none of your issues with presence subscriptions are relevant. > But it's hard for me to examine the example of the XEP-292 since I don't > fully understand the necessity of instant vcard updates notifications? > Is this for the avatar updates? If so, from/to subscriptions need to be > in game. For other people's vCards, as stpeter said, this is about ensuring that clients aren't constantly polling for change. If you need a vCard for a person in the to state, you can just send them a directed presence to turn on updates when you need them; that directed presence could potentially include an ago/off stanza to let her server know that you might not actually need the update. For people in the the from state, you probably don't have authorization to see the information, so send them a subscription request. > At least, if I imaging me a user which doesn't know anything about XMPP > under-the-hood, I think that it will be pretty non trivial for me why I > have instant vcard updates for some accounts and don't have for another > ones. I think clients have the tools they need to provide an adequate user experience, but I don't expect everyone to agree with that. >> Can you say that another way, please? I didn't quite understand your point. > > I just said that the current PEP is only useful for light protocols > which are not carry important payloads, which can be loss and nobody > cares. More complex protocols need PEP to support to/from subscription > states or they will not be able to be the high-grade and then the > situation will lead to PEP reinvention if many protocols will depend on > that PEP's issue. This argument was explicitly considered and rejected at the meeting (in Portland, I think) where we came up with PEP many years ago. Until someone comes up with a better way, some of us will implement PEP; feel free not to implement it if you don't like it. -- Joe Hildebrand
