Re: PubSubHubbub & ResourceSync Notification

Julien

Thanks for your prompt and enthusiastic reaction! 

A few things:

- I'm very happy to hear that (b) is in scope, indeed.

- In the ResourceSync Notification spec that is currently online, an additional requirement for the publisher is formulated, ie a Link specific to ResourceSync. However, we had already reached the conclusion that we should remove that to remain fully aligned with PubSubHubbub. Edits have already been made to that account but they still need to be propagated to the online version.

- I was not suggesting any explicit spec'ing of the relationship between the hub and publisher as I do understand the benefit of the open ended approach. I was merely wondering whether it would be worthwhile to have a sentence in the spec that acknowledges that both (a) and (b) are in scope. I mean, I had to ask on this list to make sure, and, especially given PubSubHubbub's Atom/RSS ancestry, that may not be clear to potential adopters.

- Related to the previous point, understanding (b) is in scope: Would eg SuperFeedr as it stands currently relay by-value XML payloads or does it expect a pointer to a feed?

Greetings

Herbert


On Mar 21, 2014, at 15:54, Julien Genestoux <julien.genestoux@gmail.com> wrote:

> Herbert,
> 
> This is a very exciting piece of news! I have personally always been convinced that PubSubHubbub could be used to build a synchronization mechanism over the web. I'm glad someone shares this vision :)
> 
> The main reason behind the 0.4 version of the spec was to decouple the mime-type from the protocol. In other words, it is about allowing the publisher to send the HTTP address of a resource of any MIME type, as well as allow subscribers to subscribe to these resources (obviously!).
> That being said your point b. is also true, because one of the consequences of the 0.4 spec is that the relationship between the publisher and the hub it picked is not formally spec'ed anymore. In practice, we found that the hub and the publishers needed to have an explicit relationship (coupling) becuase the publishers picks their hub intentionally. As such, they could agree on any 'ping' mechanism, whether it's light or fat.
> 
> To me, your approach is within the PubSubHubbub scope, provided that everything else (mostly the interactions between the subscriber and the publisher (discovery), and that the relationship between the subcsriber and the hub remain unchanged.
> 
> However, I am against any explicit spec'ing of the relationship between the hub and publishers, because what matters is that the hub is eventually able to propagate the updates to the subscribers, without considering how the hubs themselves got the information. 
> 
> Cheers!
> Julien
> 
> 
> 
> --
> Got a blog? Make following it simple: https://www.subtome.com/
> 
> Julien Genestoux,
> http://twitter.com/julien51
> 
> +1 (415) 830 6574
> +33 (0)9 70 44 76 29
> 
> 
> On Fri, Mar 21, 2014 at 9:27 PM, Van De Sompel, Herbert <herbertv@lanl.gov> wrote:
>> Hi all,
>> 
>> I wanted to inform this list that the Notification specification of ResourceSync [1] is building on the PubSubHubbub protocol. 
>> 
>> ResourceSync [2] is a synchronization framework for the Web that consists of both pull and push approaches. It is devised in a collaboration between the National Information Standardization Organization [3] and the Open Archives Initiative [4] funded by the Sloan Foundation [5].
>> 
>> Our reading of the PubSubHubbub spec and of the notes regarding PubSubHubbub v0.4 [6] is such that a decoupling of the protocol and Atom/RSS feeds is intended. However, we are not clear regarding the extent of the intended relaxation:
>> a. Is it only about allowing the publisher to send the HTTP address of a resource of any MIME type, not just of an Atom/RSS feed?
>> b. Is it also about allowing the publisher to send the payload itself (XML, but maybe also other MIME types) to the hub, rather than a pointer to it?
>> 
>> In the ResourceSync Notification spec, we have used interpretation (b) and we send XML payloads (resource change notifications) from the publisher to the hub instead of sending the location of the payload to the hub. The major motivator for this approach is that we see no need to burden the publisher with holding on to its notifications. We previously experimented with doing this over XMPP, but the introduction of a protocol other than HTTP was perceived as a significant burden. The part of the Notification spec that discusses ResourceSync's use of PubSubHubbub is at [7]. 
>> 
>> Based on the wolverine code [8], we have implemented rspush [9], a hub that can operate both in the Atom/RSS mode and in the XML payload mode. As a matter of fact, the implementation has a configuration file that allows listing those MIME types that a hub accepts as a payload. It also allows limiting the size of the payload that a hub is willing to relay.
>> 
>> => I would like to confirm whether our interpretation (b) is considered within the scope of PubSubHubbub.
>> 
>> => If it is, I am wondering whether it would be appropriate to make the possibility of a by-reference payload (pointer to a payload is sent to the hub as application/x-www-form-urlencoded ) and a by-value payload (payload itself is sent to the hub as e.g. application/xml) explicit in the PubSubHubbub spec. After all, the behavior of the hub for by-reference and by-value content delivery is rather different. 
>> 
>> => Any other feedback regarding ResourceSync's use of PubSubHubbub is very welcome.
>> 
>> Greetings
>> 
>> Herbert Van de Sompel
>> 
>> [1] http://www.openarchives.org/rs/notification
>> [2] http://www.openarchives.org/rs
>> [3] http://niso.org 
>> [4] http://www.openarchives.org 
>> [5] http://www.sloan.org/
>> [6] http://blog.superfeedr.com/pubsubhubbub-0-4/
>> [7] http://www.openarchives.org/rs/notification#Transport
>> [8] https://github.com/progrium/wolverine
>> [9] https://github.com/hariharshankar/rspush
>