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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
