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. >>>>>> >>>>> >>>>> >>> >> >
