Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 05/30/2012 01:30 AM, Peter Saint-Andre wrote: > On 5/29/12 12:27 PM, Sergey Dobrov wrote: >> On 05/30/2012 12:48 AM, Kim Alvefur wrote: >>> On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote: I don't actually understand how this XEP can work with generic (not PEP) pubsub? I have to subscribe to each pubsub service which nodes I have subscribed to? It's an overhead, isn't it? >>> >>> Isn't the reverse, ie the pubsub service needs to subscribe to you? >> >> No, generally pubsub server doesn't need my subscription. > > Unless it wants to implement presence-based delivery. Yes, but I think that it's a horror to add all of pubsub services which nodes I possibly will subscribe to. > >> So they will >> send me events even if I am offline, but I can lose some events if my >> resource was not with higher priority, and this is the problem, I think... > > In general, yes. What can we do with the problem? Since from the distributed nature of the network, I think that the only thing we can do is to assign the problem of tracking changes to the receiver's server: it can catch events and store current revision of the node and then client can be notified that some new events were received and that it should retrieve new items manually. > > Peter > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 5/29/12 12:27 PM, Sergey Dobrov wrote: > On 05/30/2012 12:48 AM, Kim Alvefur wrote: >> On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote: >>> I don't actually understand how this XEP can work with generic (not PEP) >>> pubsub? I have to subscribe to each pubsub service which nodes I have >>> subscribed to? It's an overhead, isn't it? >> >> Isn't the reverse, ie the pubsub service needs to subscribe to you? > > No, generally pubsub server doesn't need my subscription. Unless it wants to implement presence-based delivery. > So they will > send me events even if I am offline, but I can lose some events if my > resource was not with higher priority, and this is the problem, I think... In general, yes. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 05/30/2012 12:48 AM, Kim Alvefur wrote: > On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote: >> I don't actually understand how this XEP can work with generic (not PEP) >> pubsub? I have to subscribe to each pubsub service which nodes I have >> subscribed to? It's an overhead, isn't it? > > Isn't the reverse, ie the pubsub service needs to subscribe to you? No, generally pubsub server doesn't need my subscription. So they will send me events even if I am offline, but I can lose some events if my resource was not with higher priority, and this is the problem, I think... -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On Wed, 2012-05-30 at 00:47 +0700, Sergey Dobrov wrote: > I don't actually understand how this XEP can work with generic (not PEP) > pubsub? I have to subscribe to each pubsub service which nodes I have > subscribed to? It's an overhead, isn't it? Isn't the reverse, ie the pubsub service needs to subscribe to you? -- Kim Alvefur
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
I don't actually understand how this XEP can work with generic (not PEP) pubsub? I have to subscribe to each pubsub service which nodes I have subscribed to? It's an overhead, isn't it? On 05/29/2012 11:42 PM, XMPP Extensions Editor wrote: > Version 0.3 of XEP-0312 (PubSub Since) has been released. > > Abstract: This specification defines a publish-subscribe feature that enables > a subscriber to automatically receive pubsub and PEP notifications since the > last logout time of a specific resource. > > Changelog: Corrected namespace to use namespace versioning; tweaked some of > the delivery rules. (psa) > > Diff: http://xmpp.org/extensions/diff/api/xep/0312/diff/0.2/vs/0.3 > > URL: http://xmpp.org/extensions/xep-0312.html > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
pls unsubscribe me from your emails From: Joe Hildebrand To: XMPP Standards Sent: Wednesday, March 14, 2012 3:34 AM Subject: Re: [Standards] UPDATED: XEP-0312 (PubSub Since) On 3/13/12 2:55 AM, "Sergey Dobrov" wrote: > On 03/13/2012 12:52 AM, Joe Hildebrand wrote: >> >>> Another still uncovered thing is how to determine missed notifications >>> in the case of connection failures. >> >> This is really an implementation detail of how the client sets the time in >> the ago. >> > > Sure. But how it's suggested to the client to track such cases? The > client can't know when it's connection was broken but can set the "ago" > since the time last packet was received. But there's definitely no way > to detect if events were intercepted by another resource. I don't care if the events were intercepted by another resource. All I care about is the last stanza I received, or the last successful ping, or the last successful XEP-198 synchronization. The suggestion will be that you take that time, subtract from the current time, then add the longest end-to-end latency in your network, say 2 seconds as a default. Worst case, you'll get a couple of re-notifications for notifications that were in flight at the time you disconnected. > Actually, it's > not clear how pubsub service will receive the presence in case of pubsub > (and not presence) subscription. PEP. > And again the XEP will have problems with from/to subscription states.. No. PEP. It only really works with subscription='both'. -- Joe Hildebrand
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 03/15/2012 06:30 AM, Peter Saint-Andre wrote: > On 3/14/12 10:42 AM, Sergey Dobrov 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. > > Well, some non-PEP pubsub services do support presence-based > notifications, right? Actually, I don't know. I don't think that this is a good idea to subscribe each pubsub-service I ever subscribed to. > >>> 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. > > I agree that bidi subscriptions are much preferable! But why? Don't you think that one-way subscriptions are very useful for people that have many subscribers? It may be ambiguous to receive notifications and presences from all of them. One-way subscriptions are very useful here, I think. But if the one-way subscriptions will be dismissed then XMPP can't compete with proprietary analogues. That's sad. You may say that I am an idealist but it's really interesting for me to build such applications (like notorious microblogging) and it depresses me when I can't solve such fundamental things neither to find any approval that the problem is actual. Really, I fighting for XSF standards to be observed and implemented but I can't guarantee that them are useful in real life. (The real story how I tried to make juick.com to be really XMPP-compatible) > >> 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. > > It's not instant that matters necessarily, but it seems better than > polling for an updated vCard every time you log in. > >> 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. > > Some of your contacts are cooler than others. :) > > But typically I don't think you would show the user an updated vCard > unless they asked for it or tried to view it. Using pubsub just improves > things underneath (because your client doesn't need to poll). Why? It may be really useful for avatar or Full name. > > Peter > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 03/15/2012 09:06 AM, Joe Hildebrand wrote: > On 3/14/12 10:42 AM, "Sergey Dobrov" wrote: > > 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. > Ok, sorry for that. >> 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. > >> 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. > The problem is that I really like PEP but I think that this restriction is a very big limit for PEP usage. I have a possible solution for that (ejabberd developers had a patch which can solve the problem) but it will not be a standard way and it seems very dangerous to me to invent another PEP which only fixes the issue and is equal in any other thing. That's why I very afraid of XEPs like "pubsub since". -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 3/14/12 10:42 AM, "Sergey Dobrov" 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
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 3/14/12 10:42 AM, Sergey Dobrov 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. Well, some non-PEP pubsub services do support presence-based notifications, right? >> 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. I agree that bidi subscriptions are much preferable! > 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. It's not instant that matters necessarily, but it seems better than polling for an updated vCard every time you log in. > 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. Some of your contacts are cooler than others. :) But typically I don't think you would show the user an updated vCard unless they asked for it or tried to view it. Using pubsub just improves things underneath (because your client doesn't need to poll). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
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.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 3/14/12 1:32 AM, "Sergey Dobrov" wrote: > On 03/14/2012 07:04 AM, Joe Hildebrand wrote: >> On 3/13/12 2:55 AM, "Sergey Dobrov" wrote: >> >>> Actually, it's >>> not clear how pubsub service will receive the presence in case of pubsub >>> (and not presence) subscription. >> >> PEP. > > So the title of the XEP can mislead. The other thing that the same > problem exists for the regular pubsub so it will be necessary to invent > the other XEP which solve the same problem other way... 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. >>> And again the XEP will have problems with from/to subscription states.. >> >> No. PEP. It only really works with subscription='both'. >> > > I *really* can't understand which applications are suitable to solve > with such PEP restriction except of moods/tunes/etc (but pubsub since is > completely unnecessary for such applications). 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. > The real applications for which the XEP can be useful (i.e. > microblogging) are needed to be fully compliant with the regular > presences. So I think that the problem should be solved in future but > such XEPs only make the solution even harder. Can you say that another way, please? I didn't quite understand your point. > I will be pretty happy to know if I wrong but I did not even hear about > any applications PEP is needed in the current state. I mentioned XEP-292 earlier in the thread. -- Joe Hildebrand
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 03/14/2012 07:04 AM, Joe Hildebrand wrote: > On 3/13/12 2:55 AM, "Sergey Dobrov" wrote: > >> Actually, it's >> not clear how pubsub service will receive the presence in case of pubsub >> (and not presence) subscription. > > PEP. So the title of the XEP can mislead. The other thing that the same problem exists for the regular pubsub so it will be necessary to invent the other XEP which solve the same problem other way... > >> And again the XEP will have problems with from/to subscription states.. > > No. PEP. It only really works with subscription='both'. > I *really* can't understand which applications are suitable to solve with such PEP restriction except of moods/tunes/etc (but pubsub since is completely unnecessary for such applications). The real applications for which the XEP can be useful (i.e. microblogging) are needed to be fully compliant with the regular presences. So I think that the problem should be solved in future but such XEPs only make the solution even harder. I will be pretty happy to know if I wrong but I did not even hear about any applications PEP is needed in the current state. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 3/13/12 2:55 AM, "Sergey Dobrov" wrote: > On 03/13/2012 12:52 AM, Joe Hildebrand wrote: >> >>> Another still uncovered thing is how to determine missed notifications >>> in the case of connection failures. >> >> This is really an implementation detail of how the client sets the time in >> the ago. >> > > Sure. But how it's suggested to the client to track such cases? The > client can't know when it's connection was broken but can set the "ago" > since the time last packet was received. But there's definitely no way > to detect if events were intercepted by another resource. I don't care if the events were intercepted by another resource. All I care about is the last stanza I received, or the last successful ping, or the last successful XEP-198 synchronization. The suggestion will be that you take that time, subtract from the current time, then add the longest end-to-end latency in your network, say 2 seconds as a default. Worst case, you'll get a couple of re-notifications for notifications that were in flight at the time you disconnected. > Actually, it's > not clear how pubsub service will receive the presence in case of pubsub > (and not presence) subscription. PEP. > And again the XEP will have problems with from/to subscription states.. No. PEP. It only really works with subscription='both'. -- Joe Hildebrand
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 03/13/2012 12:52 AM, Joe Hildebrand wrote: > >> Another still uncovered thing is how to determine missed notifications >> in the case of connection failures. > > This is really an implementation detail of how the client sets the time in > the ago. > Sure. But how it's suggested to the client to track such cases? The client can't know when it's connection was broken but can set the "ago" since the time last packet was received. But there's definitely no way to detect if events were intercepted by another resource. Actually, it's not clear how pubsub service will receive the presence in case of pubsub (and not presence) subscription. And again the XEP will have problems with from/to subscription states.. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
On 3/11/12 4:53 AM, "Sergey Dobrov" wrote: > Still have many questions to the XEP. > > It's needed to add some examples of notifications to be sent: > > 1. How to determine that the notification is from the past and not the > current notification? The intent is that it doesn't matter; the client should use the same code path either way; the key point is that a re-publish of a given item with the same ID replaces the previous item. If you need a timestamp on the publish, the publisher should add it into the payload. > 2. Will the server send retracts or node configuration changes > notifications from the past? Yes. Perhaps we need to call out that a node could always send a purge notification, then re-publish all current items if there are too many changes to track. > Possibly, this "ago" payload should be included in presence > automatically by server since it's not always possible to determine the > value on the client side (I already gave an example when other resource > is becoming online with higher priority and then other resources can't > receive events in case of pubsub and not presence subscription). This is about the age of the cache on the client side, so the server doesn't have the information. If it's a different client, it will have a different value. > Another still uncovered thing is how to determine missed notifications > in the case of connection failures. This is really an implementation detail of how the client sets the time in the ago. -- Joe Hildebrand
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
Still have many questions to the XEP. It's needed to add some examples of notifications to be sent: 1. How to determine that the notification is from the past and not the current notification? 2. Will the server send retracts or node configuration changes notifications from the past? Possibly, this "ago" payload should be included in presence automatically by server since it's not always possible to determine the value on the client side (I already gave an example when other resource is becoming online with higher priority and then other resources can't receive events in case of pubsub and not presence subscription). Another still uncovered thing is how to determine missed notifications in the case of connection failures. On 03/09/2012 05:10 AM, XMPP Extensions Editor wrote: > Version 0.2 of XEP-0312 (PubSub Since) has been released. > > Abstract: This specification defines a publish-subscribe feature that enables > a subscriber to automatically receive pubsub and PEP notifications since the > last logout time of a specific resource. > > Changelog: Replaced jabber:iq:last with a specialized namespace. (psa) > > Diff: http://xmpp.org/extensions/diff/api/xep/0312/diff/0.1/vs/0.2 > > URL: http://xmpp.org/extensions/xep-0312.html > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] UPDATED: XEP-0312 (PubSub Since)
Still have many questions to the XEP. It's needed to add some examples of notifications to be sent: 1. How to determine that the notification is from the past and not the current notification? 2. Will the server send retracts or node configuration changes notifications from the past? Possibly, this "ago" payload should be included in presence automatically by server since it's not always possible to determine the value on the client side (I already gave an example when other resource is becoming online with higher priority and then other resources can't receive events in case of pubsub and not presence subscription). Another still uncovered thing is how to determine missed notifications in the case of connection failures. On 03/09/2012 05:10 AM, XMPP Extensions Editor wrote: > Version 0.2 of XEP-0312 (PubSub Since) has been released. > > Abstract: This specification defines a publish-subscribe feature that enables > a subscriber to automatically receive pubsub and PEP notifications since the > last logout time of a specific resource. > > Changelog: Replaced jabber:iq:last with a specialized namespace. (psa) > > Diff: http://xmpp.org/extensions/diff/api/xep/0312/diff/0.1/vs/0.2 > > URL: http://xmpp.org/extensions/xep-0312.html > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
