>
> I don't know if we need this, I would expect that it would just be
> parsed from the push URI. The way this API is currently described I
> think it is not very intuitive, e.g. if I am at /story?id=3 and I
> push the URL /images?id=6 I will end up with /images?id=3, which is
> not really what I would expect.
>
> This is setting the query string to be used on all invocations of push.
> In the chronic case, we may be pushing many 10s of associated resources
> and they all might need lang=es to be set. They may also each need an
> individual id=n to be set, but that is the part that is passed in which
> each call to push.
So maybe merging the two query strings would work, with parameters in
the URL overriding ones provided by the builder? I need to think about
this some more.
>
>
> I think we should also just have a isPushSupported() method on the
> request, so code can check if push is supported without creating a
> builder.
>
>
> I was proposing a null return.... but then I do hate having to do null
> checks. The other option is to return a Noop PushBuilder, so the code
> is not written conditionally, but just is a noop of push is not supported.
>
> Eitherway, having isPushSupported() is a reasonable addition.
I was thinking about code that might look like:
if(request.isPushEnabled()) {
generatePushedResources()
}
If all you can rely on is the null check then you you have two options,
neither of which is very nice:
if(request.getPushBuilder() != null) {
generatePushedResources()
}
Which creates a builder and discards it, which is wasteful, or:
PushBuilder builder = request.getPushBuilder();
if(builder != null) {
generatePushedResources(builder)
}
which is kinda odd if the method needs to generate multiple pushed
responses (it would have to use the passed PushBuilder for the first
one, then call getPushBuilder for the rest.
>
> Maybe also have an isPush() method so we know that the request is the
> result of a push (or is this a DispatcherType), as we may need something
> like that to avoid push loops.
This sounds reasonable, I don't really think that this should be a
DispatcherType, imho pushed requests should just have a dispatcher type
of REQUEST. If you made it a dispatcher type you would not be able to
tell if it was a pushed response inside a forward or include.
Stuart
>
> For the most part I like the idea.
>
>
> Great! I have it mostly working now for a PushCacheFilter approach.
> I'd be interested to hear how it works for a more framework centric impl
> of push (eg JSF pushing known associates rather than cached associations).
>
> I'll incorporate the feedback received and post an updated version later
> today or tomorrow.
>
> cheers
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto: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.