Jay, Thanks for the feedback. I am sorry you previously discussed some of the issues before. I guess I have missed your comments. Please see below for my responses.
On Fri, Mar 30, 2012 at 12:14 AM, Jay R. [dlvr.it] <[email protected]>wrote: > > 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". > I want 0.4 to be the reference implementation, so the MUST is probably here to stay. However, I think it's fair to tell subscribers that they may try 'older' versions of the spec if 0.4 doesn't seem to be implemented. Since there is no way to make 0.4 downward compatible, let's at least make sure it's easy to build on rather than use a bazillions subcases. > * 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) > The priority should always be to the latest version of the spec. If spec 0.4 is implemented, then that is what people should rely on. If none, then, they may try 0.3... etc. Again, I want to make the spec simple and clear enough, without too many subcases. The spec should not include the expected behavior when the spec is not implemted (doh!) > > 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. > Agreed. Let's change this to 202 Accepted. > > 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? > Kind of. Up until now, the spec assumed that the hub would always "validate" the subscription if they have been confirmed by the subscriber. This is not enough, as there are cases where the feed publisher may also decide to accept or refuse (asynchronously) the subscription. Additionnaly, there are times where a publisher may decide to "cancel" an existing subscription, which again, is not possible with the current approach. > 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 initially had the same idea, and I'm ok with that approach. > 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. > Please, let's just assume that existing implementation will need to be reworked no matter what. > > Section 6: > > * This is PubSubHubbub. Publish is not only part of the name, it's the > point of the protocol. > We indeed have had this discussion several times. > 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. > Publishers and hub MUST agree on a publishing mechanism. The rest doesn't matter. Why should the spec rule on something that anyone can decide to change without affecting anyone else? We can still list a bunch of mechanisms in an annex. > 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. > Ok with 202 instead of 200. > > * "up to some reasonable maximum over a reasonable time period" needs > better definition. > Please, provide one. > > Section 8: > > * "202 Accepted" > Ok. Thanks, Julien > > > 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] <[email protected]> | Phone: 503.896.6187 | Fax: 503.235.2216 > Website: dlvr.it | RSS: blog.dlvr.it | Support: support.dlvr.it > >
