Re: [pubsubhubbub] Re: Input on request for link relation

Hey Sam,

Sorry for the delay in my response, I've been on vacation.

On Fri, Sep 11, 2009 at 4:45 AM, Sam Johnston <samj@samj.net> wrote:
> In line with comments I've made in other threads I think it makes sense for
> us to limit link relation discussions to the generic relation itself rather
> than any specific implementation of it. I imagine the pubsubhubbub Google
> Group (blind copied as it requires subscription to post) is the appropriate
> forum for your [no doubt legitimate] concerns regarding the protocol.
> In terms of the relation, I think the description could be improved by
> dropping references to entries, Atom and RSS. It is conceivable for example
> that someone would want to be notified of an update to an HTML page (I'm
> thinking about this currently for status updates to HTML renderings of
> virtual machine resources) or indeed some other arbitrary resource. If we
> [continue to] allow relations to be bound to protocols in spite of the
> availability of content types and/or URI relations which are fit for the
> purpose we're going to back ourselves into a corner before we know it.

The proposal I submitted (for
http://www.iana.org/assignments/link-relations/link-relations.xhtml)
is to add the "hub" link relation as valid *only* for Atom documents.
Your concerns about HTML are valid in general, but not relevant in
this context as I understand things.

The protocol-specific nature of the "hub" relation is extremely
important. Like the AtomPub "edit-media" relation, the "hub" link is a
machine-readable declaration that enables software to take a specific
action on discovery (via the PubSubHubbub protocol). Without being
bound to a specific protocol this discovery mechanism becomes useless.

> Accordingly I propose the following description:
> Description: A URI for a "hub" that allows clients to register for real-time
> updates to the resource.
> The PuSH(?) group may want to consider using a URI relation and/or dedicated
> content type in addition to the generic "hub" relation.

Such an amorphous definition doesn't accomplish anything, in my view.
Hopefully what I said above makes sense. Many of the other relation
types specifically reference an RFC with the protocol definition.
PubSubHubbub is moving in that direction, and hopefully will be a real
RFC after the draft stage.

Otherwise, this is my first time interacting with any of these
standards or standards bodies, so please forgive me if I'm
misunderstanding anything or being thick-headed.

> On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <algermissen1971@mac.com>
> wrote:
>>
>> On Sep 11, 2009, at 1:31 AM, John Panzer wrote:
>>
>>> Without getting into the appropriate discussion form question, what hub
>>> resource semantics (and link relation definition) are you referring to
>>> exactly?  I can't seem to find it, and it's hard to understand your
>>> objection without it.
>>
>> Section 7.3 says:
>>
>> "If, after a content fetch, the hub determines that the topic feed content
>> has changed, the hub MUST send information about the changes to each of the
>> subscribers to the topic."
>>
>> I understand this to imply that subscribers expect the hub to definitely
>> send the notifications. What if the hub decides not to due to the number of
>> subscribers it has? Or to turn this around: how would a subscriber ever know
>> whether not receiving notifications means that there are not updates or that
>> the hub stopped sending notifications.

Jan: This is some extremely useful feedback. Could you please follow
up on the mailing list (http://groups.google.com/group/pubsubhubbub)
about this? We should be able to investigate and address your concerns
in an update to the PubSubHubbub spec!

-Brett

Received on Wednesday, 16 September 2009 19:43:13 UTC