After a more careful read here's some more comments. Changes are in red
with rationale indented below:
5.1: Hubs MUST allow subscribers to re-request subscriptions that are
already active.
Was activate. Should be either active or activated. I prefer the former.
5.1.1: The callback URL MAY contain arbitrary query string parameters
(e.g., ?foo=bar&red=fish). Hubs MUST preserve the query string during
subscription verification by adding new parameters. Existing parameters
with names that overlap with those used by verification requests will not
be overwritten, and added parameters must appear after the existing ones.
For event notification, the callback URL will be POSTed to including any
query-string parameters in the URL portion of the request, not as POST body
parameters.
The difference here is that the order of parameters can change if it does
not matter, preserving the semantics. Example: original query string
?k1=a1&k2=b1. Hub wants to add k1=a2 and k3=c1. With previous wording these
two query strings are valid: ?k1=a1&k2=b1&k1=a2&k3=c1 and ?k1=a1&k2=b1&k3=c1
&k1=a2. With the new wording, any query string where k1=a1 comes before
k1=a2 is valid. For example this is now allowed: ?k1=a1&k1=a2&k2=b1&k3=c1.
This provides flexibility in implementation without any loss of
information. The only important thing here is that k1=a1 comes before
k1=a2 which
might have a meaning for the receiver so it is preserved.
5.2: The hub verifies a subscription request by sending an HTTP [RFC2616]
GET request to the subscriber's callback URL as given in the subscription
request. This request has the following query string arguments
added(format described in Section 17.13.4 of
[W3C.REC‑html401‑19991224]):
See above comments for 5.1.1.
7: The hub MAY reduce the payload to a diff between two consecutive
versions if its format allows it.
It is important to specify that this diffing happens between two
consecutive versions and the hub will not keep infinite state to implement
this diffing. Let me explain with an example. Publisher pings the hub. Feed
contains items AB. The hub publishes AB to subscribers. Publisher pings the
hub again. Feed contains items BC. Hub publishes C to subscribers because B
was already published before. Publisher pings the hub again. Feed contains
items AD. Publisher SHOULD publish AD to subscribers and not just D. There
are several advantages to AD vs D. Publishing AD means that subscribers
which subscribed after the ABC publish will see A now. It also means that
the state the hub needs to keep to do the diffing is much smaller than
keeping all the state since the beginning of time (think of a youtube
firehose feed for example). Plus I can't think a usecase where publishing D
is better than publishing AD. That said, usually feeds on pubsubhubbub
model a stream of updates and feeds are a sliding window of this stream, so
I do not expect this difference in behavior to be visible to subscribers
for these kind of feeds.
The POST request must include the Self Link Header and a Hub Link
Header that correspond to topic's url and hub url, respectively.
Previous wording is confusing.
Additional comments:
Permanent vs Non-Permanent subscriptions. I think the behavior specified is
ok, but the way it is specified is rather confusing. Let's see how these
two subscriptions "differ":
- permanent subscription: no hub.lease_seconds is specified. But the hub
responds with hub.lease_seconds which represents how many seconds should
elapse before it attempts to refresh the subscription.
- non-permanent subscription: hub.lease_seconds is specified. The hub
responds with the hub.lease_seconds which represents how many seconds
should elapse before it attempts to refresh the subscription.
Woot? Notice the last sentence for each of the two items is the *same*. The
only difference between permanent vs non-permanent subscription is that the
subscriber does or does not provide a *hint* for hub.lease_seconds. So why
don't we stop the distinction between permanent vs non-permanent
subscriptions altogether? Notice the hub MAY choose to respect
hub.lease_seconds in the subscription request or not (5.1). Removing this
distinction from the spec will simplify it.
I think we want to specify this a little bit more.
- alkis
Google Switzerland GmbH
Brandschenkestrasse 110,
Zurich, Switzerland
8002 Zurich
On Wed, May 30, 2012 at 11:15 AM, Julien Genestoux <
[email protected]> wrote:
> I forgot to add Wordpress to that list.
>
>
>
> On Wed, May 30, 2012 at 11:08 AM, Julien Genestoux <
> [email protected]> wrote:
>
>> All,
>>
>> I think it's now important to get more feedback from these services who
>> implemented their own flavor of PubSubHubbub in the past because the
>> previous spec didn't cover their needs.
>> In my list, I have:
>> - Facebook (not sure who's in charge now, David Recordon can help?)
>> - Instagram (Emailed Shayne Sweeney)
>> - Github (Emailed Rick Olson)
>> - Flickr (Not sure who is in charge)
>> - Diaspora (not sure who is in charge...)
>>
>> I am sure there are many others. Can you help at finding them? Also, if
>> you know the people in charge at these companies, feel free to get them to
>> participate to that thread. I have already added the folks I know.
>>
>> Thanks for your precious help... we will soon get there :)
>>
>> Julien
>>
>>
>>
>> On Wed, May 30, 2012 at 10:29 AM, Julien Genestoux <
>> [email protected]> wrote:
>>
>>> Alkis,
>>>
>>> You are perfectly right. I just changed that.
>>> https://github.com/pubsubhubbub/PubSubHubbub/blob/master/pubsubhubbub-core-0.4.xml#L176
>>>
>>> Thanks for your input!
>>>
>>> julien
>>>
>>>
>>> On Wed, May 30, 2012 at 10:12 AM, Alkis Evlogimenos <[email protected]>wrote:
>>>
>>>> Hello Julien.
>>>>
>>>> In section 4 (discovery), I believe it is best to avoid explicit
>>>> mentioning of Atom or RSS and instead mention them indirectly as XML
>>>> formats. The way the section is currently worded, suggests that sitemaps
>>>> (for example) can only be discovered through link headers, but this is
>>>> problematic since link headers are not always an option for webmasters.
>>>>
>>>> Current text:
>>>>
>>>>> In the absence of HTTP Link headers, subscribers MAY fall back to
>>>>> other methods to discover the hub(s) and the canonical URI of the topic.
>>>>> If
>>>>> the topic is a Atom or RSS feed, it MAY use embedded link elements as
>>>>> described in Appendix B of Web Linking [RFC5988]. Similarly, for HTML
>>>>> pages, it MAY use embedded link elements as described in Appendix A of Web
>>>>> Linking [RFC5988]. Finally, publishers MAY also use the Well-Known Uniform
>>>>> Resource Identifiers [RFC5785] .host-meta to include the <Link> element.
>>>>
>>>>
>>>> Proposal:
>>>>
>>>>> In the absence of HTTP Link headers, subscribers MAY fall back to
>>>>> other methods to discover the hub(s) and the canonical URI of the topic.
>>>>> If
>>>>> the topic is an XML based feed, it MAY use embedded link elements as
>>>>> described in Appendix B of Web Linking [RFC5988]. Similarly, for HTML
>>>>> pages, it MAY use embedded link elements as described in Appendix A of Web
>>>>> Linking [RFC5988]. Finally, publishers MAY also use the Well-Known Uniform
>>>>> Resource Identifiers [RFC5785] .host-meta to include the <Link> element.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> On Thursday, May 3, 2012 7:43:18 PM UTC+2, Julien wrote:
>>>>>
>>>>> Blaine,
>>>>> Not sure what you mean, but I had previously updated the file there :
>>>>> http://superfeedr-misc.s3.**amazonaws.com/pubsubhubbub-**core-0.4.html<http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html>
>>>>>
>>>>> Feel free to send your changes here, and I'll make sure I reflect them
>>>>> there :)
>>>>>
>>>>> Ju
>>>>>
>>>>> On Wed, May 2, 2012 at 5:15 PM, Blaine Cook <[email protected]> wrote:
>>>>>
>>>>>> On 2 May 2012 14:01, Julien Genestoux <[email protected]>
>>>>>> wrote:
>>>>>> > All,
>>>>>> > I just pushed an updated version of this draft.
>>>>>> > It now includes the following (minor) points:
>>>>>> > - Comments/Fixes by Walter Groix,
>>>>>> > - Symetric "accepted" and "denied" when the hubs validates the
>>>>>> subscription
>>>>>> > - Use of From header (based on Blaine's feedback)
>>>>>> > - Use of Location header when "denied" to indicate that another
>>>>>> > - Allowing for discovery thru host-meta well known url.
>>>>>> >
>>>>>> > Please, feel free to review and submit any change that is
>>>>>> appropriate.
>>>>>>
>>>>>> This sounds awesome, Julien!
>>>>>>
>>>>>> My comments:
>>>>>>
>>>>>> – I'd suggest the following text for §4❡2 (major change is to use
>>>>>> RFC6415 explicitly):
>>>>>>
>>>>>> "In the absence of HTTP Link headers, subscribers SHOULD fall back to
>>>>>> other methods to discover the hub(s) and the canonical URI of the
>>>>>> topic. If the topic is a Atom or RSS feed, the publisher MAY provide
>>>>>> embedded link elements as described in Appendix B of Web Linking
>>>>>> [RFC5988], and the subscriber SHOULD use those links as per Appendix B
>>>>>> of [RFC5988]. Similarly, for HTML pages, the publisher MAY use
>>>>>> embedded link elements as described in Appendix A of Web Linking
>>>>>> [RFC5988], and subscribers SHOULD use those links as per Appendix A of
>>>>>> [RFC5988]. Finally, publishers MAY also use Web Host Metadata
>>>>>> [RFC6415] to include the <Link> element with a rel-value equal to
>>>>>> "hub" as with the other approaches; publishers SHOULD provide the JSON
>>>>>> variant of [RFC6415]. Subscribers SHOULD support this method for
>>>>>> discovery.
>>>>>>
>>>>>> OOPS.
>>>>>>
>>>>>> I started reading the spec at the link you posted and realised that
>>>>>> it's not the updated one at all. I don't know if the above comment
>>>>>> stands, but I'll hold off until the link is updated. :-)
>>>>>>
>>>>>> b.
>>>>>>
>>>>>
>>>>>
>>>
>>
>
