On 30/01/2015 21:14, Edward Burns wrote:
>>>>>> On Fri, 5 Dec 2014 19:56:10 +1100, Greg Wilkins <gregw_at_intalio.com> said:
>
> GW> another thing that I think would be helpful for implementing push is an
> GW> event for when a response is committed, but before the content has been
> GW> sent.
>
> GW> This is the perfect time for a push algorithm to extract information about
> GW> associated resources (size, etag, modified, session, set-cookies etc.) and
> GW> also a great time to start doing pushed.
>
> GW> If we try to implement push before commit,
>
> [meaning without having such an event]
>
> GW> then we may not see a newly valid session or some authority token
> GW> set in a cookie that needs to be used when creating the associated
> GW> requests. If we delay later, then the client will have already
> GW> received content and may have already issued requests for the
> GW> associated resources.
>
> [the above text is a justification for the proposed new event]
>
> GW> Would it be possible to add something like:
>
> GW> interface ServletResponseListener
> GW> {
> GW> void responseCommitted(ServletResponseEvent event);
> GW> }
>
> GW> class ServletResponseEvent
> GW> {
> GW> ServletRequest getServletRequest() {...}
> GW> ServletResponse getServletResponse() {...}
> GW> }
>
> GW> thoughts?
>
> Well, a brand new interface seems rather heavyweight. We already have
> ServletRequestEvent which has your above method getServletRequest().
> Couldn't we use that event class? Would there be any other events we
> would want on this interface?
Prior to Java 8, we had no choice but to add new interfaces since adding
new methods caused backwards compatibility problems. Since the minimum
Java version is Java 8 then lets take advantage of this language feature
and have a cleaner API.
> SD> Just to clarify, do you mean that this will get called just before
> SD> anything has been written out to the client (including headers), or do
> SD> you intend for this to be called after the headers have been written out
> SD> but before the body?
>
> SD> If you mean the latter then I am against this, as it basically means
> SD> instead of being able to write out both the headers and body in a
> SD> gathering write we need to make two separate write calls, which sucks
> SD> from a performance point of view.
>
> SD> If you mean the former then I think this is a good idea, however I am
> SD> not sure about the name (as technically it will happen before the
> SD> response is commited). Also if this is called just before commit would
> SD> we allow the user to modify headers etc in this event?
>
> GW> I have not thought to that detail yet. I'm not sure if it should be
> GW> called just before or just after the commit. I definitely agree is should
> GW> not be called inbetween the commit of the headers and the first body
> GW> content.
>
> GW> For me, the key aspect of this event is it is called AFTER the response
> GW> headers are finalised - ie can not longer be changed by either the
> GW> application (or the container?), but BEFORE the response is complete and
> GW> has had all it's content written.. at at least not waiting for all it's
> GW> content to be written.
>
> Greg, I think this proposed listener is best discussed as part of a more
> formal proposal on push. Do you think we should have a conference call
> to hash this out?
Personally, I prefer e-mail to conference calls but I'll go with the
majority.
Mark