Re: Input on request for link relation [ w/ proposed modifications to link draft ]

On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 17/09/2009, at 12:35 AM, Brett Slatkin wrote:
>
>  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".
>>
>
> The litmus test is that:
>
> * It's broadly applicable (which currently isn't true, because you're
> specific to Atom feeds)
>

Important nit: Also, RSS feeds.


> * It has an existing, stable specification (which it looks like you're
> approaching, if you submit as an Internet-Draft), and
> * It not be specific to a particular media type (which you are, at least
> for requests).
>
> So there's probably room for getting it in, especially since you're
> effectively "grandfathered". See below for more.
>
>
>  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.
>>
>
> Then why are you only bringing it to the attention of the wider world now?
> I don't mean to pick on you, but it seems like there are lots of developers
> these days who are writing protocols in secret, and then expecting the world
> to come along for the ride, no matter how badly they interact with the
> infrastructure. Pubsubhubbub (PLEASE come up with a shorter name!) isn't the
> worst in this respect by far, but still...
>
>
>  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?
>>
>
> That's a start. To my mind, you need to:
>
> 1. Accommodate things other than Atom feeds in your protocol, if only by
> leaving appropriate extension points for addressing it in a future
> (hopefully soon; lots of people are interested in this, from what I've seen)
> revision.
>
> 2. Publish as an Internet-Draft.
>
> The question that this brings to mind for me about the Link draft is
> whether this text about registered relations is appropriate:
>
> "Relation types that constrain the target IRI or context IRI (e.g., to a
> specific media type) MUST NOT be registered."
>
> Obviously, that's pretty open-ended, and generally link relation types
> shouldn't specify a media type, if they're to be broadly applicable, but
> relations like "hub" that constrain things to specific input and output
> formats for *generic* protocols (here, pub/sub) could be an exception. Read
> too broadly, and this requirement could even disallow "duplicate" as we've
> been discussing on a separate thread.
>
> My inclination at this point is to rewrite this as something like:
>
> "Registered relation types MUST NOT constrain the media type of the context
> IRI, and MUST NOT constrain the available representation media types of the
> target IRI. However, they MAY specify the behaviours (e.g., allowable
> methods, request media types) and constrain the representations of target
> resources in other ways."
>
> Thoughts?
>
> Regarding "hub" vs. "monitor" -- this is interesting to me, if not just
> because people have been talking about this sort of protocol for easily more
> than a decade, and many proposals have already been made*. As such, I think
> there's more value in something more capable than specific, lest we all
> drown in a sea of special-purpose, needlessly application-specific
> protocols.
>
> That said, I don't think you can use one link relation for both purposes,
> because even if they both took the same POST payloads, the further
> interactions beyond that (the callback to you) would also need to be
> compatible. While you could use the type attribute to distinguish between
> which protocol is in use, that's not really what it's for; the
> representation returned wouldn't be describing the protocol that was going
> to commence.
>
> Cheers,
>
>
> * I'm purposefully limiting my comments here to the impact on the link
> relations draft and registry. I have many other thoughts about pubsubhubbub
> and how suitable it is to general use; hopefully I'll have time to convey
> them separately.
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>