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.
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.
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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
