hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: HttpClient API redesign: HLCA --- http-common ---
Date Mon, 10 Jan 2005 15:26:37 GMT
Hello Oleg, everyone,

here is the idea I am having regarding the http-common
component. I am putting this in a separate mail because
I'm not sure whether it should be discussed as part of
the high level design. So feel free to ignore it.

When I think about requests and responses, the picture
that forms in my mind is a ladder (roughly). A request
will generate a response, which might trigger a followup
request (redirect, auth) which will give another response.
There might be more than one response to a single
request in the presence of 10x intermediate responses.

POST  req.1 ---> rsp.1a (100)
       |   \      |
       |    \     V
       |     --> rsp.1b (303)
       |          |
       V          V
GET   req.2 ---> rsp.2  (200)


So, when I have an HTTP request object, I would like
to be able to query for the immediate response object,
the followup request object, the ultimate response, and
so on. Similar with a response object, where I might
want to ask for the request, immediate or initial. And
for the preceeding or subsequent or final response.
Such navigational structures would be build by the
RedirectHandler and AuthChallengeHandler in http-client,
but might also be composed in a bigger scope by
applications.

So my questions are:

- Does anyone else see the need for tracking these
  relations between request and response objects?
  (If not, forget the rest ;-)

- Should that information be collected in the objects
  themselves? Then there would be query methods
  in the interfaces.

- Should that information be collected in separate
  objects instead? Then we need at least another
  interface, probably with default implementation.
  (That's why I raise this question now, while we
  are discussing an initial list of classes/interfaces
  for each component.)

I like the separate objects better. I don't have a
convicing idea for a name though.
HttpMessageTrace?
HttpPingPong?
HttpChitChat?

This idea combines nicely with asynchronous method
execution. I might ask a request whether it has been
sent already, whether there is a response, whether
there is an ultimate response. If the request is sent,
I might block until the next or ultimate response is
available, with or without timeout.

What do you think?

cheers,
  Roland


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message