I have incorporated some of the feedback received into Jetty's experimental
implementation. You can see the PushBuilder (as a class rather than
interface) here:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-server/src/main/java/org/eclipse/jetty/server/PushBuilder.java
and the push methods on request are seen at
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-server/src/main/java/org/eclipse/jetty/server/Request.java#n218
and a filter that utilizes the API is
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/PushSessionCacheFilter.java
I'm going to now gather some experience using this on our live site. I
think further progress on making this the start of a proposed standard API
will probably need to wait until other implementations catch up with
using/implementing push.
cheers
On 9 December 2014 at 07:44, Greg Wilkins <gregw_at_intalio.com> wrote:
>
>
> On 8 December 2014 at 21:42, Edward Burns <edward.burns_at_oracle.com> wrote:
>
>> >>>>> On Fri, 5 Dec 2014 11:52:01 +0100, Greg Wilkins <gregw_at_intalio.com>
>> said:
>>
>> GW> I've been working with Push a little bit more and have an alternative
>> GW> proposal for the API.
>>
>> Well, I'm sorry to see the simplicity of the existing API have to give
>> way to something that seems to be starting to get quite complex.
>>
>> GW> I've started work on this, but thought I'd seek some feedback before I
>> GW> commit too much effort. The idea is that often there will be many
>> GW> resources to push and that a lot of the work needed to work out
>> headers,
>> GW> sessions and cookies is common to all the pushes. So we need a new
>> GW> PushBuilder instance that does all this work once. We would obtain
>> a
>> GW> PushBuilder from a new method on the request:
>>
>> GW> /** Get a PushBuilder associated with this request initialized as
>> GW> follows:<ul>
>> GW> * <li>The method is initialized to "GET"</li>
>>
>> If we obtain the PushBuilder from the current request, then why would
>> the method not be taken on from the existing request?
>>
>>
> Because we cannot push POSTs and PUTs. We can push GETs and HEAD, maybe
> even OPTION and these can be pushed in association with a POST (can't think
> why a PUT would have push associates).
>
> So just trying to come up with a default that will work with minimal calls
> for most situations. Maybe it is initialised to the same method as the
> original request, unless that method is not supported by push, in which
> case it is initialised to GET.
>
>
>
>> [...]
>>
>> GW> * <p>Each call to getPushBuilder() will return a new instance
>> GW> * of a PushBuilder based off this Request. Any mutations to the
>> GW> * returned PushBuilder are not reflected on future returns.
>> GW> * @return A new PushBuilder or null if push is not supported
>> GW> */
>> GW> public PushBuilder getPushBuilder()
>>
>> I to prefer the isPushSupported() method. I think calling
>> getPushBuilder() should throw IllegalStateException if push is not
>> supported.
>>
>>
> Sounds like a converging consensus on that.
>
> cheers
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.