Thank you for the fast replies/changes. I put 2 pull requests on github. https://github.com/pubsubhubbub/PubSubHubbub/pull/17
hub.lease_seconds becomes required in the response of the hub. Because we made all subscriptions "temporary/ephemeral" IMO it makes sense to require the hub to return hub.lease_seconds so that subscribers know when to renew their subscription. https://github.com/pubsubhubbub/PubSubHubbub/pull/16 Removes a mention of temporary subscription. Since all subscriptions are temporary now, it makes no sense to mention the subscription as temporary in this context. - alkis Google Switzerland GmbH Brandschenkestrasse 110, Zurich, Switzerland 8002 Zurich On Mon, Jun 4, 2012 at 10:19 AM, Julien Genestoux < [email protected]> wrote: > Alkis, > This is brilliant. Thanks for the precious help. Please see the comments > below! > > On Fri, Jun 1, 2012 at 5:14 PM, Alkis Evlogimenos (Άλκης Ευλογημένος) < > [email protected]> wrote: > >> After a more careful read here's some more comments. Changes are in red >> with rationale indented below: >> >> 5.1: Hubs MUST allow subscribers to re-request subscriptions that are >> already active. >> >> Was activate. Should be either active or activated. I prefer the former. >> >> > Fixed! > > >> >> 5.1.1: The callback URL MAY contain arbitrary query string parameters >> (e.g., ?foo=bar&red=fish). Hubs MUST preserve the query string during >> subscription verification by adding new parameters. Existing parameters >> with names that overlap with those used by verification requests will not >> be overwritten, and added parameters must appear after the existing ones. >> For event notification, the callback URL will be POSTed to including any >> query-string parameters in the URL portion of the request, not as POST body >> parameters. >> >> The difference here is that the order of parameters can change if it does >> not matter, preserving the semantics. Example: original query string >> ?k1=a1&k2=b1. Hub wants to add k1=a2 and k3=c1. With previous wording >> these two query strings are valid: ?k1=a1&k2=b1&k1=a2&k3=c1 and >> ?k1=a1&k2=b1&k3=c1&k1=a2. With the new wording, any query string where >> k1=a1 comes before k1=a2 is valid. For example this is now allowed: >> ?k1=a1&k1=a2&k2=b1&k3=c1. This provides flexibility in implementation >> without any loss of information. The only important thing here is that >> k1=a1 comes before k1=a2 which might have a meaning for the receiver so >> it is preserved. >> >> > I am not sure this is the right thing to do. In other words, I think it > would add a lot of confusion of params with the same name appeared in the > url because the subscriber may not know which ones were added by the hub, > and which one were already present in the url... > However, I undrstand your point, but I'd like to say that I believe this > is solved more elegantly by using query param names that should not have > collisions... the hub adds query strings with a "hub." namespace. I believe > this should be sufficient. > I'd love to have a third opinion though. > > >> >> 5.2: The hub verifies a subscription request by sending an HTTP [RFC2616] >> GET request to the subscriber's callback URL as given in the subscription >> request. This request has the following query string arguments added(format >> described in Section 17.13.4 of [W3C.REC‑html401‑19991224]): >> >> See above comments for 5.1.1. >> >> > Well... same :) > > >> >> 7: The hub MAY reduce the payload to a diff between two consecutive >> versions if its format allows it. >> >> It is important to specify that this diffing happens between two >> consecutive versions and the hub will not keep infinite state to implement >> this diffing. Let me explain with an example. Publisher pings the hub. Feed >> contains items AB. The hub publishes AB to subscribers. Publisher pings the >> hub again. Feed contains items BC. Hub publishes C to subscribers because B >> was already published before. Publisher pings the hub again. Feed contains >> items AD. Publisher SHOULD publish AD to subscribers and not just D. There >> are several advantages to AD vs D. Publishing AD means that subscribers >> which subscribed after the ABC publish will see A now. It also means that >> the state the hub needs to keep to do the diffing is much smaller than >> keeping all the state since the beginning of time (think of a youtube >> firehose feed for example). Plus I can't think a usecase where publishing D >> is better than publishing AD. That said, usually feeds on pubsubhubbub >> model a stream of updates and feeds are a sliding window of this stream, so >> I do not expect this difference in behavior to be visible to subscribers >> for these kind of feeds. >> >> > I definetely agree with that.. and it's fixed! > > >> >> The POST request must include the Self Link Header and a Hub Link >> Header that correspond to topic's url and hub url, respectively. >> >> Previous wording is confusing. >> >> Fixed! > > >> >> Additional comments: >> >> Permanent vs Non-Permanent subscriptions. I think the behavior specified >> is ok, but the way it is specified is rather confusing. Let's see how these >> two subscriptions "differ": >> - permanent subscription: no hub.lease_seconds is specified. But the hub >> responds with hub.lease_seconds which represents how many seconds should >> elapse before it attempts to refresh the subscription. >> - non-permanent subscription: hub.lease_seconds is specified. The hub >> responds with the hub.lease_seconds which represents how many seconds >> should elapse before it attempts to refresh the subscription. >> >> Woot? Notice the last sentence for each of the two items is the *same*. >> The only difference between permanent vs non-permanent subscription is that >> the subscriber does or does not provide a *hint* for hub.lease_seconds. So >> why don't we stop the distinction between permanent vs non-permanent >> subscriptions altogether? Notice the hub MAY choose to respect >> hub.lease_seconds in the subscription request or not (5.1). Removing this >> distinction from the spec will simplify it. >> > > Hum. That was actually my understanding... However, I have to confess that > these "permanent" subscriptions are quite a pain to deal with... I am now > in favor of reducing the default lease duration on our hubs even. > As a matter of facts, we found out that some subscribers will accept of > verifications of intent... which means that the hub may keep stale urls > forever in their data store. I believe this is a problem on the long term. > By removing the concept of "permanent" url, we force subsribers to care > about the subscriptions they make and want to hold, so I'm in favor of > that, and i have pushed a commit (5eae049) in that direction. > Please let me know what you think! > > I think we want to specify this a little bit more. > > > Agreed! Thanks for helping out! > > - alkis > > Google Switzerland GmbH > Brandschenkestrasse 110, > Zurich, Switzerland > 8002 Zurich > > > > On Wed, May 30, 2012 at 11:15 AM, Julien Genestoux < > [email protected]> wrote: > >> I forgot to add Wordpress to that list. >> >> >> >> On Wed, May 30, 2012 at 11:08 AM, Julien Genestoux < >> [email protected]> wrote: >> >>> All, >>> >>> I think it's now important to get more feedback from these services who >>> implemented their own flavor of PubSubHubbub in the past because the >>> previous spec didn't cover their needs. >>> In my list, I have: >>> - Facebook (not sure who's in charge now, David Recordon can help?) >>> - Instagram (Emailed Shayne Sweeney) >>> - Github (Emailed Rick Olson) >>> - Flickr (Not sure who is in charge) >>> - Diaspora (not sure who is in charge...) >>> >>> I am sure there are many others. Can you help at finding them? Also, if >>> you know the people in charge at these companies, feel free to get them to >>> participate to that thread. I have already added the folks I know. >>> >>> Thanks for your precious help... we will soon get there :) >>> >>> Julien >>> >>> >>> >>> On Wed, May 30, 2012 at 10:29 AM, Julien Genestoux < >>> [email protected]> wrote: >>> >>>> Alkis, >>>> >>>> You are perfectly right. I just changed that. >>>> https://github.com/pubsubhubbub/PubSubHubbub/blob/master/pubsubhubbub-core-0.4.xml#L176 >>>> >>>> Thanks for your input! >>>> >>>> julien >>>> >>>> >>>> On Wed, May 30, 2012 at 10:12 AM, Alkis Evlogimenos >>>> <[email protected]>wrote: >>>> >>>>> Hello Julien. >>>>> >>>>> In section 4 (discovery), I believe it is best to avoid explicit >>>>> mentioning of Atom or RSS and instead mention them indirectly as XML >>>>> formats. The way the section is currently worded, suggests that sitemaps >>>>> (for example) can only be discovered through link headers, but this is >>>>> problematic since link headers are not always an option for webmasters. >>>>> >>>>> Current text: >>>>> >>>>>> In the absence of HTTP Link headers, subscribers MAY fall back to >>>>>> other methods to discover the hub(s) and the canonical URI of the topic. >>>>>> If >>>>>> the topic is a Atom or RSS feed, it MAY use embedded link elements as >>>>>> described in Appendix B of Web Linking [RFC5988]. Similarly, for HTML >>>>>> pages, it MAY use embedded link elements as described in Appendix A of >>>>>> Web >>>>>> Linking [RFC5988]. Finally, publishers MAY also use the Well-Known >>>>>> Uniform >>>>>> Resource Identifiers [RFC5785] .host-meta to include the <Link> element. >>>>> >>>>> >>>>> Proposal: >>>>> >>>>>> In the absence of HTTP Link headers, subscribers MAY fall back to >>>>>> other methods to discover the hub(s) and the canonical URI of the topic. >>>>>> If >>>>>> the topic is an XML based feed, it MAY use embedded link elements as >>>>>> described in Appendix B of Web Linking [RFC5988]. Similarly, for HTML >>>>>> pages, it MAY use embedded link elements as described in Appendix A of >>>>>> Web >>>>>> Linking [RFC5988]. Finally, publishers MAY also use the Well-Known >>>>>> Uniform >>>>>> Resource Identifiers [RFC5785] .host-meta to include the <Link> element. >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> On Thursday, May 3, 2012 7:43:18 PM UTC+2, Julien wrote: >>>>>> >>>>>> Blaine, >>>>>> Not sure what you mean, but I had previously updated the file there : >>>>>> http://superfeedr-misc.s3.**amazonaws.com/pubsubhubbub-** >>>>>> core-0.4.html<http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html> >>>>>> >>>>>> Feel free to send your changes here, and I'll make sure I reflect >>>>>> them there :) >>>>>> >>>>>> Ju >>>>>> >>>>>> On Wed, May 2, 2012 at 5:15 PM, Blaine Cook <[email protected]> wrote: >>>>>> >>>>>>> On 2 May 2012 14:01, Julien Genestoux <[email protected]> >>>>>>> wrote: >>>>>>> > All, >>>>>>> > I just pushed an updated version of this draft. >>>>>>> > It now includes the following (minor) points: >>>>>>> > - Comments/Fixes by Walter Groix, >>>>>>> > - Symetric "accepted" and "denied" when the hubs validates the >>>>>>> subscription >>>>>>> > - Use of From header (based on Blaine's feedback) >>>>>>> > - Use of Location header when "denied" to indicate that another >>>>>>> > - Allowing for discovery thru host-meta well known url. >>>>>>> > >>>>>>> > Please, feel free to review and submit any change that is >>>>>>> appropriate. >>>>>>> >>>>>>> This sounds awesome, Julien! >>>>>>> >>>>>>> My comments: >>>>>>> >>>>>>> – I'd suggest the following text for §4❡2 (major change is to use >>>>>>> RFC6415 explicitly): >>>>>>> >>>>>>> "In the absence of HTTP Link headers, subscribers SHOULD fall back to >>>>>>> other methods to discover the hub(s) and the canonical URI of the >>>>>>> topic. If the topic is a Atom or RSS feed, the publisher MAY provide >>>>>>> embedded link elements as described in Appendix B of Web Linking >>>>>>> [RFC5988], and the subscriber SHOULD use those links as per Appendix >>>>>>> B >>>>>>> of [RFC5988]. Similarly, for HTML pages, the publisher MAY use >>>>>>> embedded link elements as described in Appendix A of Web Linking >>>>>>> [RFC5988], and subscribers SHOULD use those links as per Appendix A >>>>>>> of >>>>>>> [RFC5988]. Finally, publishers MAY also use Web Host Metadata >>>>>>> [RFC6415] to include the <Link> element with a rel-value equal to >>>>>>> "hub" as with the other approaches; publishers SHOULD provide the >>>>>>> JSON >>>>>>> variant of [RFC6415]. Subscribers SHOULD support this method for >>>>>>> discovery. >>>>>>> >>>>>>> OOPS. >>>>>>> >>>>>>> I started reading the spec at the link you posted and realised that >>>>>>> it's not the updated one at all. I don't know if the above comment >>>>>>> stands, but I'll hold off until the link is updated. :-) >>>>>>> >>>>>>> b. >>>>>>> >>>>>> >>>>>> >>>> >>> >> > >
