tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposal - Comet changes
Date Wed, 16 Aug 2006 13:42:28 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 5. CometEvent
>> public class CometEvent {
>>   public enum EventType {
>> //and anything else, we could also create groups of types, 
>> READ,ERROR,SHUTDOWN, with subtypes
>>   }
>>   public HttpServletRequest getRequest();
>>   public HttpServletResponse getResponse();
>>   ...and other useful info here
>> }
>> I believe this would allow for more flexibility in the future and a 
>> cleaner interface.
>> The CometServlet can actually stay exactly the same, if need be, as 
>> the begin,end methods can be called based on service() and event()
> I still mixed on this. Switching to events is a bit more heavyweight 
> (objects, ifs blocks to handle the event type), and will cleanup the 
> interface but make the implementations slightly more complex.
The implementation is already pretty complex, there are two methods I am 
required to implement although they are never called by the container.
The CometProcessor today is hard to implement without actually reverse 
engineer the code to see what is going on.
What I am looking for, and I'm not saying the above is the final answer, 
is a more intuitive life cycle. So there are two goals:
1. Get rid of the application having to set 
request.setAttribute(bla.bla.comet), I think the fact that a servlet 
implements the CometProcessor interface should be enough
   The same thing goes for request.removeAttribute(bla.bla.comet) - 
since the container already controls the lifecycle, let it control the 
lifecycle all the way, just like a servlet
   An alternative is to provide a CometServlet that finals the service() 
method, and that way all comet communication, including the "start" 
event, is sent to the event() method.
2. When speaking of the lifecycle of the request, the CometProcessor can 
end it by calling response.getWriter().close(), unless we provide a 
close() method the event object
3. In terms of heavy weight, the entire lifecycle of the request can 
reuse the same event object, the only thing that changes in between is 
the event. so essentially, you're only pushing one object on the stack 
instead of two or three or however many arguments you have.
> What I really have a problem with is the many event types, since 
> adding more adds complexity for the application code: for starters, 
> the many error types (besides error and timeout, anything extra seems 
> useless to me) and shutdown (this portion of the code does not have 
> any business to get this sort of notifications, especially 
> differentiating between shutdown types). As you said it, it's still 
> actually down to 3 useful events: read, error and shutdown (aka, end).
I agree on the types, that is why I mention main and sub types, for the 
main. The sub types can be useful, cause an implementation may want to 
know why the request is ended or error:ed out. Its important, cause a 
simple connection timeout, the webapp developer might wanna keep his 
"push data" in a queue to push once the client opens a new connection. 
But if the webapp is reloaded, that queue should be emptied out and 
reloaded upon start again. (for example, today request attributes could 
throw a ClassCastException upon webapp reload, but if there was an 
event, the developer could actually clear those attributes out and 
reload them later). So the lifecycle of a comet servlet, is slightly 
different than a servlet.

I need to noodle on it some more to see how this can be all simplified, 
including the implementation at the end.
I'll come back with a more detailed proposal tomorrow.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message