RE: Input on request for link relation

> -----Original Message-----
> From: []
> On Behalf Of Brett Slatkin
> Sent: Wednesday, September 16, 2009 7:37 AM

> I understand part of the motivation for mnot's draft
> (, 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.
> 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.
> 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?


Received on Thursday, 17 September 2009 00:53:01 UTC