I think that using additional discovery mechanisms are a good idea here,
especially things that get the discovery info out of the body of the
resource. Using either host-meta/XRD or SWD, you basically end up
querying with a combination of a principle (in this case, the URL of the
resource you're accessing), and the service that you're after. You
construct a well-known URL on the right base with the right parameters
using a deterministic method and come back with a discovery document
that tells you where to go.
-- Justin
On 04/06/2012 08:31 AM, Julien Genestoux 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]
<mailto:[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
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
