> RE: [Vote] Vote for a new Cactus committerHi,
>
> One thing I find strange is that the response is actually stuffed in the
> method object (GetMethod, ...). So you use the method object for both
> setting the request and accessing the result. I would think it is better
to
> separate the 2 and provide a response object class.
>
> What do you think ?
>
> >>>>>>>>>>>>>>>>
>
> Others have found the design nice and intuitive for that reason.
>
> - create method object
> - set params
> - execute method
> - get results from method object
>
> >>>>>>>>>>>>>>>>
In using HttpClient for an automated testing framework, and using it within
Slide to talk to Exchange 2000, I found this feature extremely intuitive. I
would hope that would not change.
>
> Also, the default is to use the disk to store the results. Is that because
> the design is to read all waiting data from the stream at once and stuff
it
> either on disk or in memory ? This is fine for some cases but there are
> cases, when it is preferable to leave the data on the server so that it is
> consumed bit after bit during the processing logic in the application code
> ... [sorry, I haven't looked closely at the code there to know the exact
> behaviour]
>
> What do you think ?
>
> >>>>>>>>>>>>>>>>>
>
> The thing is it's very easy to replace the GET method implementation by
> another one.
> So if your app needs something different, just write a MyGetMethod class
(it
> should be only a few very simple lines of code), and forget about the
> "standard" GetMethod :-)
>
> The buffering is done to allow repeatable reads. If you don't need that,
> then the GetMethod can be much simpler.
>
In my unit testing using HttpClient, the repeatable read is very important
when I am dealing with XML (or ugly HTML), which fails to turn into a DOM,
which then runs through JTidy and then back into a DOM...
Scott
