Ho, and here is a readable version! http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html Thanks,
On Wed, May 2, 2012 at 3:01 PM, 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. > > 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 >>>>> >>>>> >>> >
