- From: Van De Sompel, Herbert <herbertv@lanl.gov>
- Date: Fri, 21 Mar 2014 20:27:46 +0000
- To: "public-pubsub@w3.org" <public-pubsub@w3.org>
- CC: Herbert Van de Sompel <hvdsomp@gmail.com>
- Message-ID: <DCE93A3F-C524-49FE-97D8-8B53331A9774@lanl.gov>
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
Received on Friday, 21 March 2014 20:28:17 UTC