Hi Tanaka!

> I don't like the API.
> 
> Since there are many ways to control behavior, "first proc argument is
> for progress bar" is not intuitive.
> 
> How about another API?
> open(name, :progress_proc => lambda {|pos| ... })

i had it this way at first! :) but then i realized that it is dependent on special symbol :progress_proc -or- it must determine based on value class Proc but then what do you do with more than one Proc is in hash? plus the keys are meaningless then too. so i think it is better as an independent argument. it is an optional argument. so there is no backward compatability problems.

also it can be used for anything, not just progressbar. any proc that takes byte argument will work.
 
> open-uri emulates usual file instead of pipe.
> I think it should be default at least.
> 
> There are many subtle difference between file and pipe:
> * various exception by network problem may be raised at (first) read
>   time instead of open time.
> * pipe is unseekable.
> * cannot get actual file size for pipe. (Content-Length may be invalid)
> * cannot support rw mode.
> * etc.
> 
> However optional pipe emulation mode is acceptable, maybe.

hmm... the reason i had to make this patch is because as soon as i called open, all excution stopped until finished download. i needed to get inside of download loop to give progress. so i meant by IO is that the block is yeilded in the download loop rather then after it. hey maybe that's a better way to do it!? but it may break things?

thanks, let me know what you think,
-t0