[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Input on request for link relation [ w/ proposed modifications to link draft ]
On 21/09/2009, at 1:43 PM, Brett Slatkin wrote:
Thanks for the reply.
On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <mnot@xxxxxxxx>
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
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
October 2008) and it's difficult to go back to ask everyone to
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
these days who are writing protocols in secret, and then expecting
to come along for the ride, no matter how badly they interact with
infrastructure. Pubsubhubbub (PLEASE come up with a shorter name!)
worst in this respect by far, but still...
Brad and I have been showing this protocol around for a while. We
showed it off at an XMPP users group meeting in February
and multiple blog posts were written about it in the beginning of this
year (http://tinyurl.com/mjvgy6) around Social Web Foo 2009. I'm not
hooked into any standards bodies at all; is there some
protocol-announce mailing list I should have used?
Obviously, I don't read the right blogs. :) Ideally people would have
communicated this internally inside the IETF as well as in various
companies that were working on it, but we don't live in that ideal
world. Ah, well.
The best place to socialise this sort of thing in the IETF is probably
the apps-discuss list; <https://www.ietf.org/mailman/listinfo/apps-discuss
>. In the W3C, it's probably www-talk; <http://lists.w3.org/Archives/Public/www-talk/
So, this is how I would modify your description from before to be
Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
that enables clients to register for and publish real-time updates
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
leaving appropriate extension points for addressing it in a future
(hopefully soon; lots of people are interested in this, from what
I've opened this bug to track leaving open extensions for future
We need to figure out how discovery will work (possibly XRD?) but I
think it's doable.
2. Publish as an Internet-Draft.
The question that this brings to mind for me about the Link draft
this text about registered relations is appropriate:
"Relation types that constrain the target IRI or context IRI (e.g.,
specific media type) MUST NOT be registered."
Obviously, that's pretty open-ended, and generally link relation
shouldn't specify a media type, if they're to be broadly
relations like "hub" that constrain things to specific input and
formats for *generic* protocols (here, pub/sub) could be an
too broadly, and this requirement could even disallow "duplicate"
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
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
resources in other ways."
I like the second description here much more. It's a nice improvement
on the original language.
Good, I think so too.
Before PubSubHubbub is made into a
legitimate internet draft, we'll need a better story for all content
types (issue 71 filed above).
Regarding "hub" vs. "monitor" -- this is interesting to me, if not
because people have been talking about this sort of protocol for
than a decade, and many proposals have already been made*. As such,
there's more value in something more capable than specific, lest we
drown in a sea of special-purpose, needlessly application-specific
That said, I don't think you can use one link relation for both
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
which protocol is in use, that's not really what it's for; the
representation returned wouldn't be describing the protocol that
I can't seem to find any reference to the "monitor" relation type
anywhere. Could you pass me a link to it?
with a mailing list at:
* I'm purposefully limiting my comments here to the impact on the
relations draft and registry. I have many other thoughts about
and how suitable it is to general use; hopefully I'll have time to
I would really appreciate if you could find the time. I could really
use some help from you and others who are familiar with the
standardization process. This is all new to me.
Mark Nottingham http://www.mnot.net/