Would anyone miss GetMethod.setUseDisk()?

["Kalnichevski, Oleg" <ol...@bearingpoint.com>]

Folks,

It looks like I am about to stir another trouble in the HttpClient's Middle-earth. I can't help thinking that the whole disk buffering logic in the GetMethod class is kind of flaky and moreover absolutely pointless. What is the first this that you usually do after creating an instance of GetMethod or PostMethod? Let me guess. You set setUseDisk flag to false. Disk buffering simply does not belong to the HTTP GET method. Period. 

Would you miss it if it was gone? I would not.

Olegolas

Re: Would anyone miss GetMethod.setUseDisk()?

[Jeffrey Dever <js...@sympatico.ca>]

>
>
> If we did this, I think we'd want to do it as a module that sat on top 
> of httpclient, rather than as a core part of httpclient itself.  Maybe 
> even a separate jar, but part of the same build or something.


Thats quite exciting actually.  There is a whole machine for starting 
and taking on projects like this, the commons incubator.  I think that 
the scope of a HttpCache is just right for a commons project (HttpClient 
is actually quite large).  After all, there is a FileUpload component!

Cool stuff.  I think you could have quite a bit of support for this Laura.

Jandalf.

Re: Would anyone miss GetMethod.setUseDisk()?

[Laura Werner <la...@lwerner.org>]

Ortwin Glück wrote:

>> One possible enhancement to 2.1 would be to add a Cache module which 
>> would work like a web browser cache to write gets to file and refers 
>> to the cache before pulling the resource again.  Just a thought.
>
>
> Cool, if this is something our users want. I don't want to build in 
> functionality that nobody uses, though. 

I've already got one of these, actually.  The API isn't very pretty, 
though: you access it by asking it for a File, and it either returns the 
cached file or downloads a new one and then returns that, depending on 
whether the old one is expired.  It obeys all the messy HTTP 1.1 caching 
rules and everything.  I've been debating whether to change it to 
parallel the normal httpclient API instead, and may do that when I 
re-integrate it with the Alpha 2 release of httpclient.  Though I think 
you'd still want a way of asking for the File too, because sometimes 
that's what the client really wants, after all.

After httpclient 2.0 is finished (-:), I can see if the powers that be 
here are willing to make this open source.  My boss's boss once managed 
the IBM project that  turned into Apache XML and I once managed an IBM 
i18n project that we open-sourced, so there's a good chance we'd be willing.

If we did this, I think we'd want to do it as a module that sat on top 
of httpclient, rather than as a core part of httpclient itself.  Maybe 
even a separate jar, but part of the same build or something.

Laura Werner
BeVocal

Re: Would anyone miss GetMethod.setUseDisk()?

[Ortwin Glück <or...@nose.ch>]

Jeffrey Dever wrote:
> I agree that the disk buffering methods are obsolete.  Its trivial for a 
> user to wrap our outputstream  into a fileoutputstream.  However, we 
> must remember that we are building a library as opposed to an 
> application and such be careful what we remove.  Methods that don't make 
> sense anymore should be deprecated for 2.0, but not removed untill 2.1

Good point.

> One possible enhancement to 2.1 would be to add a Cache module which 
> would work like a web browser cache to write gets to file and refers to 
> the cache before pulling the resource again.  Just a thought.

Cool, if this is something our users want. I don't want to build in 
functionality that nobody uses, though.

> <ha ha>
> Odo, like Frodo
> Ortagorn, like Aragorn
> Odomir, like Boromir
> Odli, like Gimli
> Ortrond or Elwin like Elrond
> </ha ha>

Orthanc, maybe? (hostname of my home computer actually)

Re: Would anyone miss GetMethod.setUseDisk()?

[Ryan Hoegg <rh...@isisnetworks.net>]

Jeffrey Dever wrote:

> One possible enhancement to 2.1 would be to add a Cache module which 
> would work like a web browser cache to write gets to file and refers 
> to the cache before pulling the resource again.  Just a thought. 

 From a library user: +1!

Re: Would anyone miss GetMethod.setUseDisk()?

[Jeffrey Dever <js...@sympatico.ca>]

I agree that the disk buffering methods are obsolete.  Its trivial for a 
user to wrap our outputstream  into a fileoutputstream.  However, we 
must remember that we are building a library as opposed to an 
application and such be careful what we remove.  Methods that don't make 
sense anymore should be deprecated for 2.0, but not removed untill 2.1

One possible enhancement to 2.1 would be to add a Cache module which 
would work like a web browser cache to write gets to file and refers to 
the cache before pulling the resource again.  Just a thought.

Jandalf

<ha ha>
Odo, like Frodo
Ortagorn, like Aragorn
Odomir, like Boromir
Odli, like Gimli
Ortrond or Elwin like Elrond
</ha ha>

Ortwin Glück wrote:

> Olegolas,
>
> Before unbuffered response (getResponseBodyAsStream) was introduced, 
> disk buffering was the only work around for big downloads. This has 
> become obsolete as you correctly state. I think we can simply remove 
> disk buffering and provide an example that gets the response stream 
> and writes it to a file.
>
> Odi
>
> Kalnichevski, Oleg wrote:
>
>> Folks,
>>
>> It looks like I am about to stir another trouble in the HttpClient's
>> Middle-earth. I can't help thinking that the whole disk buffering
>> logic in the GetMethod class is kind of flaky and moreover absolutely
>> pointless. What is the first this that you usually do after creating
>> an instance of GetMethod or PostMethod? Let me guess. You set
>> setUseDisk flag to false. Disk buffering simply does not belong to
>> the HTTP GET method. Period.
>>
>> Would you miss it if it was gone? I would not.
>>
>> Olegolas
>
>
>
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>

Re: Would anyone miss GetMethod.setUseDisk()?

[Ortwin Glück <or...@nose.ch>]

Olegolas,

Before unbuffered response (getResponseBodyAsStream) was introduced, 
disk buffering was the only work around for big downloads. This has 
become obsolete as you correctly state. I think we can simply remove 
disk buffering and provide an example that gets the response stream and 
writes it to a file.

Odi

Kalnichevski, Oleg wrote:
> Folks,
> 
> It looks like I am about to stir another trouble in the HttpClient's
> Middle-earth. I can't help thinking that the whole disk buffering
> logic in the GetMethod class is kind of flaky and moreover absolutely
> pointless. What is the first this that you usually do after creating
> an instance of GetMethod or PostMethod? Let me guess. You set
> setUseDisk flag to false. Disk buffering simply does not belong to
> the HTTP GET method. Period.
> 
> Would you miss it if it was gone? I would not.
> 
> Olegolas