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. Thanks! On Fri, Apr 6, 2012 at 3:41 PM, vrypan <[email protected]> wrote: > "at least in theory" > > I wouldn't mind if sitemap.xml used pubsubhubbub to notify interested > parties like search engines of changes. > http://www.sitemaps.org/protocol.html#informing > > P. > > > On Friday, April 6, 2012 3:31:33 PM UTC+3, Julien wrote: >> >> Hi! >> >> Thanks for the feedback! Indeed, HTTP resources can be anything... at >> least in theory, and I'm expecting some specific use cases to break that >> theory :) >> >> I perfectly understand and agree that using HTTP headers is a bit of a >> constraint. However, as you've noted, if we want to be able to provide a >> protocol that "works" with any type of content, we cannot put these >> elements in the HTTP body. >> >> Your suggestion about using a "well known" url is interesting and I like >> it. I'd love to have feedback from folks like Blaine or Evan on this, >> because this could very well be a viable alternative. >> >> Julien >> >> >> >> On Fri, Apr 6, 2012 at 12:39 PM, vrypan <[email protected]> wrote: >> >>> Hi, >>> >>> I like the way HTTP headers are used. >>> >>> However, I would like to see an alternative place to store this kind of >>> information other than the HTTP headers, because "advanced" HTTP header >>> manipulation is out of reach for many users and in many cases: form complex >>> CMSs, to simple hosting solutions like Amazon S3 (I tried to set a "Link:" >>> header and it looks like s3 will not accept it). >>> >>> I think that it would be useful if 4.Discovery described an alternative >>> fallback mechanism based on some reasonable convention. For example, >>> something like an extended sitemap.xml that includes rel=pub resources for >>> each URL, and the client would look up if everything else fails. >>> >>> It's not as elegant as the HTTP headers, but it should be much easier >>> for many publishers to implement, IMHO. Would you consider something like >>> this, or is it totally out of the philosophy pubsubhubbub is designed? >>> >>> P. >>> >>> On Thursday, March 29, 2012 11:02:12 PM UTC+3, Julien wrote: >>> >>>> All, >>>> >>>> I hope you're doing well. >>>> For the past couple months, me and several other people tried to >>>> identify >>>> how we could make PubSubHubbub better, by fixing some of its issues, >>>> but also opening the door to more use cases (private resources... etc). >>>> It is based on a lot of experience that we have accumulated by hosting >>>> some of the biggest hubs out there, but also conversations we've had >>>> with publishers who sometimes didn't go down the PubSubHubbub way. >>>> >>>> We came to the conclusion that there was no way we could make 0.4 >>>> downward compatible because 0.3 makes too many assumption on the >>>> types of resources (Atom or RSS feeds). >>>> >>>> Here is a project of how the spec could evolve. We have already got >>>> a lot of feedback from people who implemented the previous spec >>>> but also from people who want to implement it now that it solves some >>>> of the issues. >>>> >>>> Git repo (feel free to check out): >>>> https://github.com/**pubsubhubbu**b/PubSubHubbub/**tree/future<https://github.com/pubsubhubbub/PubSubHubbub/tree/future> >>>> >>>> Human readable version at: >>>> https://superfeedr-misc.s3.**ama**zonaws.com/pubsubhubbub-**core-** >>>> 0.4.html<https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html> >>>> >>>> I would personally appreciate your constructive feedback. >>>> >>>> Thanks, >>>> >>>> Julien >>>> >>>> >>> On Thursday, March 29, 2012 11:02:12 PM UTC+3, Julien wrote: >>> >>>> All, >>>> >>>> I hope you're doing well. >>>> For the past couple months, me and several other people tried to >>>> identify >>>> how we could make PubSubHubbub better, by fixing some of its issues, >>>> but also opening the door to more use cases (private resources... etc). >>>> It is based on a lot of experience that we have accumulated by hosting >>>> some of the biggest hubs out there, but also conversations we've had >>>> with publishers who sometimes didn't go down the PubSubHubbub way. >>>> >>>> We came to the conclusion that there was no way we could make 0.4 >>>> downward compatible because 0.3 makes too many assumption on the >>>> types of resources (Atom or RSS feeds). >>>> >>>> Here is a project of how the spec could evolve. We have already got >>>> a lot of feedback from people who implemented the previous spec >>>> but also from people who want to implement it now that it solves some >>>> of the issues. >>>> >>>> Git repo (feel free to check out): >>>> https://github.com/**pubsubhubbu**b/PubSubHubbub/**tree/future<https://github.com/pubsubhubbub/PubSubHubbub/tree/future> >>>> >>>> Human readable version at: >>>> https://superfeedr-misc.s3.**ama**zonaws.com/pubsubhubbub-**core-** >>>> 0.4.html<https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html> >>>> >>>> I would personally appreciate your constructive feedback. >>>> >>>> Thanks, >>>> >>>> Julien >>>> >>>> >>
