This "dialog" tracking would come in very handy in a few applications here. It would especially be nice if the "dialog" context could be maintained over several requests. Maybe passed in to the execute like the state object is now.
-----Original Message----- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 7:27 AM To: HttpClient Project Subject: Re: HttpClient API redesign: HLCA --- http-common --- 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
