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

Hey Mark,

Thanks for the reply.

On Wed, Sep 16, 2009 at 10:51 PM, Mark Nottingham <mnot@mnot.net> 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?

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

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

-Brett

Received on Monday, 21 September 2009 08:19:20 UTC