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