Alkis, Sorry for the delay; I was traveling to SF and it takes forever from Europe! I merged the changes... thanks again!
Julien On Wed, Jun 6, 2012 at 10:31 AM, Alkis Evlogimenos (Άλκης Ευλογημένος) < [email protected]> wrote: > 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. >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> >> >
