Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44E33D6F.7000001@hanik.com>
Date: Wed, 16 Aug 2006 10:44:47 -0500
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Proposal - Comet changes
References: <44DCB252.8010204@hanik.com> <44E2E90C.8000504@apache.org>
 <44E320C4.2090105@hanik.com> <44E33033.9020202@apache.org>
In-Reply-To: <44E33033.9020202@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Filip Hanik - Dev Lists wrote:
>>>> 5. CometEvent
>>>>
>>>> public class CometEvent {
>>>>   public enum EventType {
>>>>     
>>>> READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR 
>>>> //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.
>
> I see all that as a bit equivalent. I don't see why the implementation 
> of the CometServlet (or the example ChatServlet) is complex.
let me tell you why, if I extend the CometServlet, which I must since it 
is abstract, I would assume I can override the begin method, expecting 
to have begin called, but if I don't call super.begin, the 
implementation no longer works cause the org.apache.tomcat.comet never 
gets set. The docs for it doesn't say I have to set this attribute. so 
without reverse engineering the source code, it would be hard to 
implement this. Granted some of the complexity could just be lack of 
documentation.
So by implementing CometProcessor or extending CometServlet, I think we 
can safely assume that the request is a comet request instead of having 
to explicitly call request.setAttribute,
we can still use the attribute internally.
>
> About 1) and 2), I thought about it and it is indeed possible to 
> remove the attribute, but more explicit mechanisms looked less error 
> prone to me (after all, there are plenty of people out there who flush 
> and close the request at the end of their service methods ...). It 
> also gives a choice to the user to trigger or not comet IO based on 
> some other things.
flush I can see, but close in a comet I can't, there is no way to send 
additional data after close is called, as that is a output stream close 
method.
calling close, will/should eventually trigger event(END).
>
>>>
>>> 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.
>
> Ok.
>
>> 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.
>
thanks for the feedback!, more to come :)
Filip


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org