I think we need an unambiguous way to determine whether a particular hub
for a particular resource is for whole-document update notifications or
whether it's capable of format-specific delta notifications. That way
subscribers will know what to expect before the subscribe and find that
they aren't getting the kind of notification they wanted.
Here's a strawman:
If the hub is published in a Link: header, then the hub handles
whole-document updates agnostic to the type of the body.
Otherwise, the hub is declared inside the entity body in a
format-specific way. In this case, the resource format and the
notification format are defined by whatever specification defined how to
find the hub URL.
This is consistent with the capabilities we'd expect consumers of this
information to have anyway; you can't parse the atom:link in Atom/RSS or
the "hubs" property in my JSON proposal without having support for those
specific payload formats, but that's okay because you wouldn't have been
able to parse the update notifications anyway.
On 06/06/2010 11:55 AM, Monica Keller wrote:
This is what I am proposing
If you want to subscribe to a resource look at the response headers.
First look for rel="hub" using web linking as described
http://code.google.com/p/pubsubhubbub/wiki/ArbitraryContentTypes
If not present look at the content-type and map the hub location. We
currently know how to map application/atom+xml and application/rss+xml
We need a content type for JSON activity streams or JSON feeds.
Something more specific than
application/json
Ex: application/feed+json then we can describe having a "hubs" element
or whatever we decide.
I think using http headers will be quite useful as we can syndicate
csv, excel,jpgs etc
Take a look at the wiki page if you have a chance and let me know what
you think.
On Jun 5, 5:58 pm, Martin Atkins<[email protected]> wrote:
On 06/05/2010 02:47 PM, Monica Keller wrote:
Cool !
Bret and I met on Friday and agreed on the minimal changes needed to
support arbitrary formats in PubSubHubbub
I will post what we discussed on the wiki in detail but its pretty
straightforward just using HTTP Headers
Web Linking for hub and topic url and Date header for update date.
So I guess this would just monitor an entire resource and post the
updated version to the subscriber whenever it changes, rather than
dividing the resource into logical "items" and delivering them separately?
That seems like a fine fallback for non-stream-like resources like
images but I do think it's useful to define a more granular stream
format for JSON so that it can be used to deliver things like activity
streams more efficiently.
