Container <-> protocol dependancy

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Heya all,

Here is an issue (which was brought up before,
but didn't get discussed enough ;-)

Question: should servlet container actually know
what kind of servlet it is calling now. i.e. Should it
know exactly that this particular request will be
handled by HttpServletRequest derivative
(and thus pass HttpServletRequest and HttpServletResponse
to service() method).

Another option would be for container to create
ServletRequest and ServletResponse objects,
which would only describe and pass data of the request,
while servlet itself figures out if that data is in fact
adequate for its protocol.

First approach simplifies implementing servlet
containers that only support single protocol (i.e. HTTP).
Second one allows container to handle multiple
protocols in clean manner.

Why was it brought up?
I am looking at Krzysztof's public API, and
HttpServlet::service(ServletRequest&, ServletResponse&)
is implemented as follows:

void  HttpServlet::service(ServletRequest& req, ServletResponse& res) {
    HttpServletRequest &request =
        dynamic_cast<HttpServletRequest&>(req);
    HttpServletResponse &response =
        dynamic_cast<HttpServletResponse&>(res);
    service(request, response);
}

Last time I wanted to do API separation, and was discussing it with
Alex Shor, idea was to do something along the lines of:

void  HttpServlet::service(ServletRequest& req, ServletResponse& res) {
    HttpServletRequest  request (req);
    HttpServletResponse response(res);
    service(request, response);
}

In this case HttpServletRequest/Response constructor would use
wrapped object to extract HTTP-specific data, and implement non-HTTP
specific functions by delegating them to wrapped object.

In the latter case, there would be single data transfer and servlet mapping
code, but actual protocol interpretation would be left to mid-layer
that would sit on top of base API.

Ideas, comments, everyone?

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com