Re: Using PUSH to refresh a previously requested resource?

I may not be understanding properly, but isn't what you're talking about
solved with a request whose response doesn't return until the server wants
it to (a.k.a. hanging get)?

-=R


On Wed, Jul 3, 2013 at 12:42 AM, Ben Niven-Jenkins
<ben@niven-jenkins.co.uk>wrote:

> Colleagues,
>
> I've been pondering the use of server push in non-browser environments. As
> currently designed server push is meant for pushing resources associated
> with the originally requested resource. Unless I've missed something it
> doesn't allow for the server to push an updated version of a previously
> requested resource.
>
> What I'm thinking of is something like a webservice where the client is
> regularly polling the server for a resource (e.g. completion status of a
> running 'job') where the server may decide it is advantageous to push a
> refreshed/updated version of the resource to provide a more timely update
> to the client (e.g. as soon as the 'job' completes) rather than waiting for
> the client to next poll for itself.
>
> I read the semantics of PUSH_PROMISE as roughly "based on the request you
> made here are some different resources associated with the one you
> requested that might be useful" but the semantics I think I need are "based
> on the request you made here is an updated version of that resource" or
> possibly (I need to think about it more) "based on a previous request you
> made here is an updated version of that resource 'piggybacked' on a
> response to a request for a different resource".
>
> Am I being overly restrictive in my interpretation of associated and an
> updated resource is in fact 'associated' with the older version of the same
> resource?
>
> The piggybacking of a PUSH for an unrelated resource (i.e. not referenced
> in the requested resource) doesn't appear to be accommodated by the (spirit
> of the) current spec but it's not clear to me if it's actively prohibited
> or just that the current spec wording implies (to me) it is not
> intended/allowed without saying so explicitly.
>
> Thanks
> Ben
>
>
>
>

Received on Wednesday, 3 July 2013 07:48:18 UTC