Hey Scott,
Looks like what you are implementing is HttpUnit (or something very
similar), isn't it ? :)
Cheers,
-Vincent
----- Original Message -----
From: "Scott Sanders" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 14, 2001 6:06 PM
Subject: Re: HttpClient and response design
> > Hi,
> >
> > 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
>
>
