Re: Requesting reviews of Provenance Access and Query document.

27.03.2013 00:20, Ashok Malhotra:
> Could Web Sockets http://www.w3.org/TR/websockets/ be used as a PUSH
> mechanism?
Server-Sent Events [1] are more suited.

[1] http://dev.w3.org/html5/eventsource/

Best,
Dominik

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


-- 
Dominik Tomaszuk
Research Fellow
University of Bialystok
Poland

Received on Wednesday, 27 March 2013 00:13:37 UTC