In article <E1AKpQU-0006TK-JH / fetch-bak.runbox.com>,
  "T. Onoma" <transami / runbox.com> writes:

> 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.

I may also want to use proc for:
* process content fragments instead of byte count.
* handle request/response header for *each* request by redirection.
  (for authentication, cookie, etc.)
* etc.

In future, open may have many proc arguments as:

open(name, progress_proc, content_progress_proc,
  extra_request_header_proc, handle_response_header_proc, ...)

I don't like that.
I don't want to remember the order.
I don't want to specify number of nil for arguments I don't care.

So, although it has no backward compatibility, it has extensibility
problem.

> 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?

Do you know pipe of Unix?
-- 
Tanaka Akira