Re: Input on request for link relation

Hi Sam,

On Wed, Sep 16, 2009 at 3:13 AM, Sam Johnston <samj@samj.net> wrote:
> On Wed, Sep 16, 2009 at 8:15 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> In the current link draft, relations shouldn't have dependencies on the
>> media types of what's linked to, and it looks like both the request and
>> response content is constrained in this proposal.
>>
>> Why not use an extension relation type (i.e., unregistered URL) instead of
>> a registered one? That allows the protocol to define things much more
>> closely, because it will "own" the relation type.
>
> I tend to agree that such standards should be strongly encouraged to use URI
> relations (at least while waiting for approval, but perhaps also on an
> ongoing basis) and that clients should accept both. One way to precipitate
> this would be to reject this application, giving reference to the existing
> 'monitor' relation (which per Adam Roach above "was to be used for both
> polling *and* passive mechanisms").
> I see that the applicant (copied) owns http://pubsubhubbub.org/ which would
> be as good a URI as any to use, but they could also use the Google Code site
> or a PURL. Being able to resolve directly back to the specification rather
> than going via the registry would presumably be advantageous too. In any
> case it's not clear to me how this registration will help interoperability
> given the constraints Mark referred to above and Brett in this thread:
>>
>> The protocol-specific nature of the "hub" relation is extremely important.
>> Like the AtomPub "edit-media" relation, the "hub" link is a machine-readable
>> declaration that enables software to take a specific action on discovery
>> (via the PubSubHubbub protocol). Without being bound to a specific protocol
>> this discovery mechanism becomes useless.
>
> Indeed if competitive standards like PubSubHubbub and rssCloud were to share
> the relation (at least without clarifying with a content type) then it could
> ironically cause interoperability problems. Note also that the motivation
> for the application was Atom compliance which would be achieved with a URI
> relation. That's not to say it's any less of a standard, just that the
> relations registry is intended for generic relations (at least going
> forward).

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

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.

Also, on second thought, I should have pointed out that others
(namely, Jeff Lindsay) advocate making PubSubHubbub a generic protocol
that's not specific to any particular content type. This would enable
the protocol to push event-based Atom, RSS, text, arbitrary XML, HTML,
raw bytes, etc. I've pushed back on this because I don't want to lose
focus on the use-case of feeds (because it's immediately useful), but
I think making this protocol more generic in the future is a good
idea.

So, this is how I would modify your description from before to be more generic:

Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
that enables clients to register for and publish real-time updates to
the resource.

How does that sound?

-Brett

Received on Wednesday, 16 September 2009 19:43:00 UTC