Hi Tim, Sorry for the delay in getting back to you and thanks again for the thorough review.
I've wrapped the "noted" ones from this list into this language meta-bug (http://code.google.com/p/pubsubhubbub/issues/detail?id=94). The other one I'd like more feedback on. On Sun, Oct 18, 2009 at 12:45 AM, Tim Bray <[email protected]> wrote: > Abstract: "Polling sucks" > > Who cares? I disagree, think polling has scaled astoundingly well > with the HTTP infrastructure, but the goodness of PuSH holds even if > polling is in fact widely appropriate for lots of situations. This > could put people off and is orthogonal to the real issues, so I'd lose > this assertion. Noted. > 2. Definitions/Event: "An event that's visible to multiple topics." Do > you mean an event that causes updates in multiple topics? If so, why > not just say so? I find "visible to" a bit confusing. Noted. > 3. High-level Protocol Flow, last bullet point. "The hub caches > minimal metadata..." I read this a few times and it seems to be > describing one particular implementation strategy. If so, why not say > so? The current language makes it look like this is maybe a normative > part of what you have to do to implement PuSH, which I'm pretty sure > it isn't. I think this is intended to be normative. A stateless hub can't function properly (doing feed diffs). The language here was chosen specifically to imply stateful handling of content without dictating the specific implementation. > 4. Atom Details. Why is this here? The term "truncated" is a little > weird, not used in Atom; in fact it's just a summary-only entry. I > guess, although it doesn't actually say, that this is a sample of what > a publisher might send a hub, intentionally leaving things out (why?) > and relying clients to follow the links for the <entry>s they're > interested in. Assuming this is what you mean, the section needs a > little motivation, explaining what it's illustrating. I.e. an > introduction saying what this is an example of, and a bit more depth > on why you might choose one way or another of approaching this. Noted. > 4. Atom details. I quote: > > <!-- Context entry that's meta-data only and not new. Implied because > the > update time on this entry is before the //atom:feed/updated > time. --> > > Huh? Sorry, I don't get what "Implied" means. Clearly, this isn't the > entry that caused the feed updated time. But in principle you could > have batched up a few entry updates into one publisher=>hub update, so > the fact that the updated is different doesn't seem to imply anything > to me. What am I missing? Indeed this piece has confused a few people. We need to ditch this. > 5. Last para says you SHOULD use HTTPS (wouldn't TLS be a better > term?) but the example above doesn't. Noted. > 6.1.2 in the first sentence, the word "already" surprised me. Perhaps > "successfully" might be a bit more straightforward? Noted. -Brett
