Re: Requesting reviews of Provenance Access and Query document.

Could Web Sockets http://www.w3.org/TR/websockets/ be used as a PUSH mechanism?
All the best, Ashok
On 3/26/2013 5:26 PM, Erik Wilde wrote:
> hello graham.
>
> thanks for your email!
>
> On 2013-03-14 9:44 , Graham Klyne wrote:
>> The section on pingbacks
>> (http://www.w3.org/TR/2013/WD-prov-aq-20130312/#forward-provenance) is
>> intended to provide a way for a publisher to learn about additional
>> provenance related to a published resource.  We would be interested to
>> hear from web services experts if they have any experience of using HTTP
>> in this way, and if there are any known problems with the proposed
>> approach.  (The PROV WG has agreed to drop the implied directionality in
>> the name used and description.)
>
> if understand this correctly, this is supposed to be some kind of push mechanism, instead of the usual pull model. there is little in terms of standardized/widely deployed technology on the web so far. browsers have been using "long pulls", but that's not very scalable and mostly because of some restrictions inherent to browsers.
>
> the connection to LDP is a very interesting one, because there could be an interesting opportunity to leverage LDP's model. for this, i'll explain how this actually does work in Atom (which has a similar model of collections/entries). Atom provides feeds that most often are sorted by date. PuSH (PubSubHubbub, a now defunct google activity) defined a model that allowed people for subscribe to feeds by registering a callback URI. for any update in the feed, the PuSH server would package the update as an Atom entry and then POST it to the callback URI.
>
> this being a pubsub model, this means that the PuSH servers much maintain subscriber lists (of all callback URIs). in PuSH, this can be layered, because a feed can advertise a hub for it (where clients can go and subscribe). While PuSH worked, it never gained critical mass, and was hampered by the fact that there was no standardized protocol how to subscribe/unsubscribe, so that was left for implementers to figure out. a more promising protocol should probably cover this aspect as well.
>
> to summarize: when LDP is stable, it would be conceivable for LDP services to support a similar service: clients interested in updates would subscribe to a URI, and would get pushed updates in the form of LDP data (which would be exactly the same as they would have gotten when GETting the updates resource), thanks to the RESTfu design of the protocol: URIs are the interaction points for resources, and we can build protocols (such as this LDP/PuSH design) on top of it.
>
> in fact, some PuSH implementations were even smart enough to batch push messages: when a client subscribed to multiple collections, or several updates happened, they would send "batch updates" that would be POSTed to the callback URI. the listening "client" would then act as if it had seen multiple updates getting published in the feed (had it used pull interactions).
>
> LDP is definitely pull only, allowing you to GET resources at well defined URIs (GET the collection and GET all updates, GET individual resources and GET all data about them), so we will provide the right foundation in terms of a RESTful design. layering LDPush on it actually would be a nice validation of the benefits of RESTfu design, but would require additional protocol parts (probably) such as how to handle subscription and unsubscription.
>
> implementation issues also arise in terms of scalability: how to deal with millions of subscribers? many PuSH implementations chose to handle this pragmatically and just automatically cancel subscriptions (requiring clients to refresh periodically), thus making it easier for servers to deal with the problem of subscriptions piling up because clients subscribed and never bothered to unsubscribe.
>
> kind regards,
>
> dret.
>

Received on Tuesday, 26 March 2013 23:23:09 UTC