Responses inline.
On 21/09/2009, at 1:43 PM, Brett Slatkin wrote:
Hey Mark,
Thanks for the reply.
On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <[email protected]>
wrote:
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...
Brad and I have been showing this protocol around for a while. We
showed it off at an XMPP users group meeting in February
(http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/
)
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
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.
I've opened this bug to track leaving open extensions for future
content types:
http://code.google.com/p/pubsubhubbub/issues/detail?id=71
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
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?
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
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.
I can't seem to find any reference to the "monitor" relation type
anywhere. Could you pass me a link to it?
See:
http://tools.ietf.org/html/draft-roach-sip-http-subscribe
with a mailing list at:
https://www.ietf.org/mailman/listinfo/sip-http-events
* 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.
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.
Will do.
Cheers,
--
Mark Nottingham http://www.mnot.net/
