Re: PubSubHubbub & ResourceSync Notification

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/
<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
>
>