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

Reply via email to