>>>>> 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?
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?
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 26 days til DevNexus 2015
| 36 days til JavaLand 2015
| 46 days til CONFESS 2015