Re: Using PUSH to refresh a previously requested resource?

Don't be afraid to push us if we're getting this wrong :)
-=R


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

>
> On 3 Jul 2013, at 09:33, Roberto Peon wrote:
>
> > A hanging-get, assuming the resource isn't marked cacheable, would be
> end-to-end.
> > A PUSH, however, is currently intended to be point-to-point right now,
> as opposed to end-to-end.
>
> Ah! I'd overlooked that aspect of PUSH, thanks. Ben
>
> >
> > Perhaps that shouldn't be (but I think it should) and you can convince
> everyone about it :)
> > Or if it should be, perhaps there needs to be another version to support
> your use-case through a proxy.
> >
> > -=R
> >
> >
> > On Wed, Jul 3, 2013 at 12:57 AM, Ben Niven-Jenkins <
> ben@niven-jenkins.co.uk> wrote:
> >
> > On 3 Jul 2013, at 08:47, Roberto Peon wrote:
> >
> > > 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)?
> >
> > Yes it could be, I was pondering whether PUSH could be used to make it
> server driven instead.
> >
> > Ben
> >
> > >
> > > -=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
> > >
> > >
> > >
> > >
> >
> >
>
>