"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/**pubsubhubbub/PubSubHubbub/**tree/future<https://github.com/pubsubhubbub/PubSubHubbub/tree/future> >>> >>> Human readable version at: >>> https://superfeedr-misc.s3.**amazonaws.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/**pubsubhubbub/PubSubHubbub/**tree/future<https://github.com/pubsubhubbub/PubSubHubbub/tree/future> >>> >>> Human readable version at: >>> https://superfeedr-misc.s3.**amazonaws.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 >>> >>> >
