Suggestion: async response redirection

[roynasser]

Reading up on http://progrium.com/blog/2012/12/06/async-http-responses-with-response-redirection/ / http://progrium.com/blog/2012/11/26/x-callback-header-an-evented-web-building-block/ got me to thinking...

I'm not really sure how useful this would be, but it would definitely be "cool" to have supported at the API Framework level...

Basically a responder that responded with a provisional "202" (or error) code, and then waited for the process to finish and posted or otherwise submitted the result via HTTP to the supplied URL...

What do you guys think? utterly useless?

[Arul-]

This is interesting, will look at the possibilities 👍

[roynasser]

Arul, I have another use where it may be interesting to return a "status" (such as Success or 200OK), and then upon execution do something like feed a DB with a return...

Would there be any way of supporting something like this? A responder/format class wouldnt work I think as it only gets invoked when I "return" the data, right? Would there be a way of having a class return a status immediately and then pass on the result returned by each function onto a specific handler?

It would be a way to implement the above, also a way of implementing a DB writer, or other sort of delayed response mechanism...

Alternatively, using a que mechanism could also work, but a restler-based solution could work and be simpler for many cases?

[yankeeinlondon]

This is precisely what I was looking for a few months back. I think there are a lot of performance use cases where this would be a huge win. I think while the article suggests time and event triggers galore I think 80/20 rule would just to be to start to think of the client response as a part of the workflow but not only the end of the workflow. If all we had were the ability to provide a callback hook to resume immediate execution once the client has been responded to that would address most of the needs IMO.

[roynasser]

I hadnt seen this @ksnyde ... sorry... any ideas on how to implement?

rgds

[yankeeinlondon]

Have been quite distracted so have to say no for now but if this is still on the drawing boards in a month or so then I will give it some attention. In the mean time, very interested in anything you come up with (or happy to be a sounding board for any ideas).

[roynasser]

I'm also swamped right now... But one thing that has come to mind is a job-based system... Basically when the request goes in to the API, a job is scheduled to execute the request and then callback the appropriate hook or whatever...

We could do that with any message/job queue in theory... I may try something like this with PHP-Resque as that is the job system we use. I wont have time for that right now though... :/

[yankeeinlondon]

Sounds smart. Time is the enemy it appears (maybe it always is). :)