Re: Input on request for link relation

Hey Eran,

>> I understand part of the motivation for mnot's draft
>> (http://www.ietf.org/id/draft-nottingham-http-link-header-06.txt), but
>> it doesn't remove the need for registered link relations. It seems
>> that the litmus test for registration is whether the relation is
>> "broadly useful".
>
> I think it puts the burden on you to come up with a broadly useful *definition* to the relation type that will not limit it just for ATOM. Since you also indicated below that there is already talk about such ideas, this would not be a waste of your time.
>
> You spec will then be putting limits on it in the context of specific protocols for clients that chose to adopt it.

Yeah, I think that's a fair assessment.

>> In that regard, it's important to note that PubSubHubbub is live for
>> over 100 *million* feeds as of this writing. It is consumed by dozens
>> of companies and developers from multiple countries. There are
>> implementations of publisher and subscriber clients in many
>> programming languages. There are even new companies with private
>> investment running hubs. We've had the genie out of the bottle (since
>> October 2008) and it's difficult to go back to ask everyone to change
>> things now.
>
> While I have sympathy for this argument as I have made it for OAuth (the answer was, compared to say, TCP or HTTP, OAuth is at best slightly adopted...), it both isn't that hard and not a reason for the web to get stuck with a poorly designed link. Now I am not arguing it is poorly design (I wouldn't know - I didn't read it yet), but just that this reason is not enough to formalize protocols when they are poorly design.

I agree with you. The spec has been receiving peer review for almost a
year now. More feedback would be great
(http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html).

>> Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
>> that enables clients to register for and publish real-time updates to
>> the resource.
>
> Why does it have to speak only that protocol? Is that a requirement? Are there other protocols?

My concern is discovery. The link relation declares to machines that
the PubSubHubbub protocol may be used with the resource and indicates
that the publisher of the resource has delegated publish/subscribe
responsibility to another URI (the Hub in the href).

If "hub" does not indicate the protocol, then how will machines
determine if PubSubHubbub is supported? Probing the URI endpoint to
see what it returns? Doing some kind of XRD lookup? All of these
solutions *could* work, but they are vastly more complex than the
simplicity of declaring the endpoint outright. This is why we have
links in the first place!

Long-term, I would like to consider that PubSubHubbub could move in
the direction of being a standard way of doing publish/subscribe for
all resources available via HTTP. We're just not there yet. We could
use everyone's help in making sure the specification can/will support
this in the future.

-Brett

Received on Thursday, 17 September 2009 08:21:29 UTC