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. > > 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. 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. 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. > > 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. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
