I see several problems, at least one of which I know has been discussed
before.
Section 4:
* Discovery is self-conflicting. "HTTP response from the publisher MUST
include at least one Link Header
<https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html#RFC5988>"
[...] "In the absence of HTTP Link headers, subscribers MAY fall back to other
methods to discover the hub". Changing MUST to SHOULD would solve this,
however I believe that alternate methods such as for HTML and feeds should be
explicitly defined, not dictated to the vague "MAY use embedded link elements".
* Behavior should be defined for when http headers and body content conflict
with each other by specifying differing self or hub links. Which one takes
priority? I would imagine content wins, since it's closest to the source. (a
la CSS - element-embedded styles always win out over classes or IDs)
Section 5.2.1: (See also Section 7)
* This should be either 201 Created, or 202 Accepted, not "any 200". These
codes have meanings - let's use them. It makes no sense for a server to issue
a "206 Partial Content" as a response for accepting a subscription, so it
shouldn't be allowed.
Section 5.2.2:
* I'm trying to understand this section, because it's worded confusingly.
This is a final handshake after verifying the subscription? The hub must
immediately push the current state of the subscribed topic? The subscription
can be denied by the hub after final verification occurs? If I'm
understanding this, I'd prefer that the accept and denial were handled the
same. "accepted" or "denied", not <push content> vs. "denied". I say this
because I don't keep a "current topic state" in a retrievable location for the
publishing system - a queue of outgoing requests is maintained by the backend
when new updates arrive from publishers, and if that queue is empty, there's
nothing to send.
Section 6:
* This is PubSubHubbub. Publish is not only part of the name, it's the
point of the protocol. Publisher and Hub CAN agree on a separate publishing
mechanism outside of the spec, but the spec MUST include a standard, universal
mechanism that all hubs implement or absolutely no code can be written which
applies the spec but is reusable on any hub. Ideally this would be a push
notification of its own, but that adds additional security concerns between
the hub and publisher, so a simple ping using the content URL (as in the 0.3
spec) is sufficient.
Section 7:
* I've tried to advocate against the "any 200 is success" idea since the
beginning. In my opinion, a successful push MUST respond with a 202
Accepted. Anything else MUST be considered a failure, and continued failures
should prompt a subscription verification attempt. Allowing for 200 responses
means that a hub will continue to publish to an incorrectly configured site,
(perhaps one which has relocated endpoints, or shutdown, or had their hostname
expire, etc.) until such a time as subscription verification occurs which, if
you use pushpress as an example, is ten years from now.
* "up to some reasonable maximum over a reasonable time period" needs better
definition.
Section 8:
* "202 Accepted"
On 3/29/2012 1:02 PM, Julien Genestoux wrote:
All,
I hope you're doing well.
For the past couple months, me and several other people tried to identify
how we could make PubSubHubbub better, by fixing some of its issues,
but also opening the door to more use cases (private resources... etc).
It is based on a lot of experience that we have accumulated by hosting
some of the biggest hubs out there, but also conversations we've had
with publishers who sometimes didn't go down the PubSubHubbub way.
We came to the conclusion that there was no way we could make 0.4
downward compatible because 0.3 makes too many assumption on the
types of resources (Atom or RSS feeds).
Here is a project of how the spec could evolve. We have already got
a lot of feedback from people who implemented the previous spec
but also from people who want to implement it now that it solves some
of the issues.
Git repo (feel free to check out):
https://github.com/pubsubhubbub/PubSubHubbub/tree/future
Human readable version at:
https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html
I would personally appreciate your constructive feedback.
Thanks,
Julien
--
Jay Rossiter | Jack of All Trades
[email protected] <mailto:[email protected]> | Phone: 503.896.6187 | Fax:
503.235.2216
Website: dlvr.it <http://dlvr.it/> | RSS: blog.dlvr.it
<http://blog.dlvr.it/> | Support: support.dlvr.it <http://support.dlvr.it/>
