What would anyone rather do a fall Saturday, in between child-care,
than review a draft?
First off: I'm a fan. I think PuSH is a big deal and will say so in
public as required. Since I have a home-grown blog publishing system,
thought I'd write an adapter, so I read the draft. Unfortunately I've
read more draft specs than any human should ever have to, so the
editorial fine-toothed-comb came out, sorry. This note covers style
suggestions, and there are a few follow-ups that address specific
technical issues. Please consider all these as friendly edits.
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.
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.
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.
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.
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?
5. Last para says you SHOULD use HTTPS (wouldn't TLS be a better
term?) but the example above doesn't.
6.1.2 in the first sentence, the word "already" surprised me. Perhaps
"successfully" might be a bit more straightforward?
-Tim
