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/pubsubhubbub/PubSubHubbub/tree/future > > Human readable version at: > 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/pubsubhubbub/PubSubHubbub/tree/future > > Human readable version at: > https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html > > I would personally appreciate your constructive feedback. > > Thanks, > > Julien > >
