- From: John Panzer <jpanzer@acm.org>
- Date: Fri, 11 Sep 2009 11:34:11 -0700
- To: Jan Algermissen <algermissen1971@mac.com>
- Cc: Lisa Dusseault <lisa.dusseault@gmail.com>, Atom-Syntax Syntax <atom-syntax@imc.org>, ietf-http-wg@w3.org, bslatkin@google.com
- Message-ID: <30ac519d0909111134t78222aa7obb3deaaf8d5ffdcf@mail.gmail.com>
Jan -- The text you're concerned about is part of the draft protocol at http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#contentdistributionso I think this is a (legitimate) question/critique of the draft spec and should be taken up over at http://groups.google.com/group/pubsubhubbub. (+Brett). On Thu, Sep 10, 2009 at 4:57 PM, 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 > > > > > >> On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen < >> algermissen1971@mac.com> 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 >> >> >> >> >
Received on Friday, 11 September 2009 18:34:56 UTC