Re: Input on request for link relation

[Sam Johnston <samj@xxxxxxxx>]

Jan et al,

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.

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.

Kind regards,

Sam

On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <algermissen1971@xxxxxxx> 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

On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen <algermissen1971@xxxxxxx> wrote:

Lisa,

not sure the following it is appropriate to discuss this here, so please redirect me to the proper place if so.

Hubs are being discovered by clients by way of the 'hub' link relation. I am
concerned that the semantics of a hub resource (provided by the link relation
definition) are imposing obligations on the server that are contrary what one
would expect to see in the HTTP world.

Or in other words: I think that the assumptions a client makes about the behaviour
of a hub are too rigid. If a hub has more subscribers than it knows it can handle
it might well decide not to notify them. A situation like this is impossible to
prevent by the specification and I think the server should therefore explicitly be
given much more freedom regarding its behavior upon a ping.

Especially given the use of Atom which in a sense implies a very unconstrained
protocol.

(Sorry if this discussion is already going on elsewhere)

Jan



On Sep 10, 2009, at 7:30 PM, Lisa Dusseault wrote:


Comments welcome on the following request

thx,
lisa

---
General Request for Assignments (link-relations)

Contact Name :
Brett Slatkin

Type of Assignment :
I want to add a new Atom Link Relation type for the PubSubHubbub protocol

(http://pubsubhubbub.googlecode.com). The relation type is "hub".

Registry :
http://www.iana.org/assignments/link-relations/link-relations.xhtml


Description :
The new  is used for discovery of Hubs,
which enables real-time notifications of entries in Atom and RSS feeds.
Without making the relation type official, we're not in compliance with the

Atom spec.

Additional Info :
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.1.html