Async callback [was Re: SQI: Related Work to SPARQL Protocol]

On 5/13/05, Kendall Clark <kendall@monkeyfist.com> wrote:

>   4. Finally, as to the synchronous and asynchronous styles of query,
>      again, we're tied pretty closely, by charter, to HTTP, and that
>      dictates a synchronous style of interaction. Asynchronous query
>      is possible in HTTP, if you add some stuff, but we haven't really
>      talked about this at all. I don't know if WSDL's SOAP bindings
>      give you asynchrony at all; if so, we might not have to solve
>      this ourselves. But asynchrony hasn't come up in discussion, at
>      least that I remember; and we certainly never took that on as a
>      design objective or requirement.

I was wondering about this following experiments where I have a
SPARQL-fronted store with limited performance and intermittent
connectivity. Those factors are annoying misfortunes in my own case,
but more generally I should think one or both of these is likely to be
common. The latency might not be a problem for many applications, and
full transaction support may not be needed, just a moderately robust
means of getting the results from B to A sometime soon.

A possible approach that occurred to me was using the simple GET style
of query, with an additional callback URI as an extra parameter. The
server would respond immediately with an OK, but pass the query into a
queue (or whatever). Once the server had the query results available,
it would act as a client and pass the data as the content of a POST
(or PUT) to the supplied callback URI. Whether or not it would be
worth going to the trouble of putting a time limit on the response
delay or even repeats, I'm not sure; I suspect that successful/don't
know would be adequate in many circumstances.

Cheers,
Danny.   

-- 

http://dannyayers.com

Received on Friday, 13 May 2005 15:50:27 UTC