Re: Input on request for link relation

Hi Eran,

>> 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!
>
> I (obviously) share your concerns. I have recently spent months looking into the use of 'describedby' vs. other protocol-specific relation types for WebFinger, OpenID, generic resource descriptor discovery, etc. If you are looking for a simple and predictable solution, a URI extension relation type is the best solution.
>
> But it is also worth asking:
>
> * Is anything bad will happen if someone tries to talk PSHB to an endpoint linked as 'hub', which doesn't support it?

Probably not.

> * Are there currently other protocols likely to use this? Are they likely to operate side by side for the same feed?

Hopefully there will be a bunch of companion/extension protocols to
the core PubSubHubbub spec that make it function efficiently for all
content types. But no, there aren't any other protocols I know of, at
this point that would also use this <link> relation. The only other
one that comes close is rssCloud, which has its own element in the RSS
namespace.

> * How often does the protocol requires the processing of hub links? What would be the comparative cost of an additional discovery roundtrip?

Each time a feed event is delivered, the Hub link will be delivered
with it. This is necessary to handle hub moves (especially at a high
rate, which may be useful for load balancing). I think a discovery
round trip would slow things down and vastly complicate subscriber
implementations. The primary purpose of this spec is to be easy to use
for everyone; I don't want to undermine that.

> I also want to point out that we really need to work on our messaging and perception that URI extension relation type are in any way inferior or "less cool" than the short registered ones. The sooner protocol authors accept this as a perfectly valid choice for their protocol needs, the better the link framework will be.

So far, the amount of push-back I've received trying to get into the
registry has reinforced the idea that links with the URI extension
relation aren't good enough to be accepted as standards.

-Brett

Received on Monday, 21 September 2009 08:19:11 UTC