Re: Using PUSH to refresh a previously requested resource?

I certainly do like the use case and would love to have that capability,
however I think it falls more into the domain of websockets or some other
subprotocol layered on top of the framing layer alongside the http
semantics. Keeping a narrower focus for push resources is best.
On Jul 3, 2013 1:41 AM, "Roberto Peon" <grmocg@gmail.com> wrote:

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