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)
* 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/
