You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <GG...@seagullsoftware.com> on 2010/03/31 19:37:15 UTC
[IO] Progress Monitor
Hi All:
We use [io] for our server, which is great, but when looked at using it from our Eclipse based tools, I found the lack of support for monitoring a blocker.
What about providing and support and pluggable progress monitor, preferable with the same features as:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html
The interface methods are:
beginTask(String, int)
done()
internalWorked(double)
isCanceled()
setCanceled(boolean)
setTaskName(String)
subTask(String)
worked(int)
We might not only provide implementations as example, a NullProgressMonitor and a ConsoleProgressMonitor.
thoughts?
Gary Gregory
Senior Software Engineer
Seagull Software
email: ggregory@seagullsoftware.com
email: ggregory@apache.org
www.seagullsoftware.com
RE: [IO] Progress Monitor
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
> Sent: Thursday, April 08, 2010 04:03
> To: Commons Developers List
> Subject: Re: [IO] Progress Monitor
>
> On Wed, Apr 7, 2010 at 12:09 AM, Gary Gregory
> <GG...@seagullsoftware.com> wrote:
> [..]
> > When I am copying a directory containing possibly hundreds of files, I do
> want to know how far along I am. Recall that File
> >objects describe both files and directories.
>
> Good point.
>
> > The progress monitor itself can decide if the operation is fast enough to
> not bother with providing actual progress feedback. For example, Eclipse does
> not bring up the progress dialog if an operation is fast enough. This is a
> subtlety left to progress monitor implementations though.
>
> Yes, but in Eclipse the decision is based on a timer and it doesn't
> need support from a ProgressMonitor interface or the monitored
> service.
>
> What level of details would copy(File,File) provide when copying a
> deep directory structure? What performance penalty would it cause.
> What about users who don't need progress monitoring?
You use the current API. For example, a made-up example:
FileUtils.copy(File, File) stays as is. A new method is created:
FileUtils.copy(File, File, ProgressMonitor)
You only use the API you need.
We cannot remove the (File,File) API of course. We could deprecate it but that does not seem right for this compoenent.
Internally, it makes sense for the (File,File) method to call (File,File,ProgressMonitor) API with null or a NullProgressMonitor (which does nothing). It seems easier to pass in a NullProgressMonitor instead of checking for null all over the place.
Gary
>
> --
> Pozdrawiam / Best Regards
> Rafal Krupinski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
RE: [IO] Progress Monitor
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
> Sent: Thursday, April 08, 2010 04:03
> To: Commons Developers List
> Subject: Re: [IO] Progress Monitor
>
> On Wed, Apr 7, 2010 at 12:09 AM, Gary Gregory
> <GG...@seagullsoftware.com> wrote:
> [..]
> > When I am copying a directory containing possibly hundreds of files, I do
> want to know how far along I am. Recall that File
> >objects describe both files and directories.
>
> Good point.
>
> > The progress monitor itself can decide if the operation is fast enough to
> not bother with providing actual progress feedback. For example, Eclipse does
> not bring up the progress dialog if an operation is fast enough. This is a
> subtlety left to progress monitor implementations though.
>
> Yes, but in Eclipse the decision is based on a timer and it doesn't
> need support from a ProgressMonitor interface or the monitored
> service.
>
> What level of details would copy(File,File) provide when copying a
> deep directory structure? What performance penalty would it cause.
> What about users who don't need progress monitoring?
I would expect at least file and directory names to be passed to the progress monitor. For files above a certain size, above the internal copy buffer size for example, I would expect the PM to be called with "i of n K" type of messages. The idea is to be able provide data for the same kind of feedback you see in Eclipse or in the Windows explorer UI when copying files. I do not see any performance overhead beyond the method call to the PM and what the PM decides to do obviously. The File object are already constructed and the file name and file sizes are known. The URLs the length is not know but you know how far you've gone so far.
Gary
>
> --
> Pozdrawiam / Best Regards
> Rafal Krupinski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Progress Monitor
Posted by Rafał Krupiński <r....@gmail.com>.
On Wed, Apr 7, 2010 at 12:09 AM, Gary Gregory
<GG...@seagullsoftware.com> wrote:
[..]
> When I am copying a directory containing possibly hundreds of files, I do want to know how far along I am. Recall that File
>objects describe both files and directories.
Good point.
> The progress monitor itself can decide if the operation is fast enough to not bother with providing actual progress feedback. For example, Eclipse does not bring up the progress dialog if an operation is fast enough. This is a subtlety left to progress monitor implementations though.
Yes, but in Eclipse the decision is based on a timer and it doesn't
need support from a ProgressMonitor interface or the monitored
service.
What level of details would copy(File,File) provide when copying a
deep directory structure? What performance penalty would it cause.
What about users who don't need progress monitoring?
--
Pozdrawiam / Best Regards
Rafal Krupinski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [IO] Progress Monitor
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
> Sent: Tuesday, April 06, 2010 14:21
> To: Commons Developers List
> Subject: Re: [IO] Progress Monitor
>
> On 06.04.2010 19:03, Gary Gregory wrote:
> >> -----Original Message-----
> >> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
> >> Sent: Tuesday, April 06, 2010 03:59
> >> To: Commons Developers List
> >> Subject: Re: [IO] Progress Monitor
> [...]
> >> interface ProgressMonitor{
> >> void begin(int whole);
> >> void progress(int current);
> >> void end();
> >> }
> >>
> >> would suffice.
> >> What methods would you add this progress monitor support to?
> >> IOUtils.copy/Large - for sure, anywhere else?
> >
> > Everywhere a stream is used for input or output. Everywhere a File is used.
> I would like to replace my custom code with IOUtils and FilUtils calls to read
> from URL input streams and File objects pointing to network drives. Reading
> from local files that are large enough on a slow laptop drive needs feedback.
> >
> > I see adding a version of a method foo(...) with foo(..., ProgressMonitor)
> where foo(...) calls the other method with a NullMonitor.
> >
> > The API also needs to be able to see a message as part of the progress, so
> your version of begin() is too restrictive. You need to be able to say
> "Copying file Foo" and "Reading x of n KB", etc. The Eclipse folks have this
> pretty well figured out by now :)
>
> You want me to copy some bytes from one place to another and the source and
> the destination is provided by you.
> This is one operation, do I really have to tell you what am I doing? I'd say
> you know better.
>
> You can have your ConsoleProgressMonitor with task name and pretty messages,
> but copy() method really doesn't
> have to know that.
When I am copying a directory containing possibly hundreds of files, I do want to know how far along I am. Recall that File objects describe both files and directories. When I am copying one file, large or not, I do want to know how far along since the copying can be slow, especially across a network.
The progress monitor itself can decide if the operation is fast enough to not bother with providing actual progress feedback. For example, Eclipse does not bring up the progress dialog if an operation is fast enough. This is a subtlety left to progress monitor implementations though.
>
> BTW, since you've mentioned copying streams, I would add 'void begin();' to be
> used when the size of the input
> is unknown.
When you are copying from a URL for example, you indeed do not know how big the source is but you do know how much you have consumed, so it still makes sense to convey x of y type of progress. You can even set up a size guess depending on the typical file size for you application. In Eclipse, when the size is unknown, you just start progress with a total work unit of 1.
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Progress Monitor
Posted by Rafał Krupiński <r....@gmail.com>.
On 06.04.2010 19:03, Gary Gregory wrote:
>> -----Original Message-----
>> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
>> Sent: Tuesday, April 06, 2010 03:59
>> To: Commons Developers List
>> Subject: Re: [IO] Progress Monitor
[...]
>> interface ProgressMonitor{
>> void begin(int whole);
>> void progress(int current);
>> void end();
>> }
>>
>> would suffice.
>> What methods would you add this progress monitor support to?
>> IOUtils.copy/Large - for sure, anywhere else?
>
> Everywhere a stream is used for input or output. Everywhere a File is used. I would like to replace my custom code with IOUtils and FilUtils calls to read from URL input streams and File objects pointing to network drives. Reading from local files that are large enough on a slow laptop drive needs feedback.
>
> I see adding a version of a method foo(...) with foo(..., ProgressMonitor) where foo(...) calls the other method with a NullMonitor.
>
> The API also needs to be able to see a message as part of the progress, so your version of begin() is too restrictive. You need to be able to say "Copying file Foo" and "Reading x of n KB", etc. The Eclipse folks have this pretty well figured out by now :)
You want me to copy some bytes from one place to another and the source and the destination is provided by you.
This is one operation, do I really have to tell you what am I doing? I'd say you know better.
You can have your ConsoleProgressMonitor with task name and pretty messages, but copy() method really doesn't
have to know that.
BTW, since you've mentioned copying streams, I would add 'void begin();' to be used when the size of the input
is unknown.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [IO] Progress Monitor
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Rafał Krupiński [mailto:r.krupinski@gmail.com]
> Sent: Tuesday, April 06, 2010 03:59
> To: Commons Developers List
> Subject: Re: [IO] Progress Monitor
>
> On Wed, Mar 31, 2010 at 7:37 PM, Gary Gregory
> <GG...@seagullsoftware.com> wrote:
> > Hi All:
> >
> > We use [io] for our server, which is great, but when looked at using it from
> our Eclipse based tools, I found the lack of support for monitoring a blocker.
> >
> > What about providing and support and pluggable progress monitor, preferable
> with the same features as:
> >
> >
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/
> reference/api/org/eclipse/core/runtime/IProgressMonitor.html
>
> I think progress monitoring would be a nice feature, but unless IO
> supports copying directories recursively, there's no need for named
> tasks and subtasks.
> Simple
>
> interface ProgressMonitor{
> void begin(int whole);
> void progress(int current);
> void end();
> }
>
> would suffice.
> What methods would you add this progress monitor support to?
> IOUtils.copy/Large - for sure, anywhere else?
Everywhere a stream is used for input or output. Everywhere a File is used. I would like to replace my custom code with IOUtils and FilUtils calls to read from URL input streams and File objects pointing to network drives. Reading from local files that are large enough on a slow laptop drive needs feedback.
I see adding a version of a method foo(...) with foo(..., ProgressMonitor) where foo(...) calls the other method with a NullMonitor.
The API also needs to be able to see a message as part of the progress, so your version of begin() is too restrictive. You need to be able to say "Copying file Foo" and "Reading x of n KB", etc. The Eclipse folks have this pretty well figured out by now :)
>
> --
> Pozdrawiam / Best Regards
> Rafal Krupinski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Progress Monitor
Posted by Rafał Krupiński <r....@gmail.com>.
On Wed, Mar 31, 2010 at 7:37 PM, Gary Gregory
<GG...@seagullsoftware.com> wrote:
> Hi All:
>
> We use [io] for our server, which is great, but when looked at using it from our Eclipse based tools, I found the lack of support for monitoring a blocker.
>
> What about providing and support and pluggable progress monitor, preferable with the same features as:
>
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html
I think progress monitoring would be a nice feature, but unless IO
supports copying directories recursively, there's no need for named
tasks and subtasks.
Simple
interface ProgressMonitor{
void begin(int whole);
void progress(int current);
void end();
}
would suffice.
What methods would you add this progress monitor support to?
IOUtils.copy/Large - for sure, anywhere else?
--
Pozdrawiam / Best Regards
Rafal Krupinski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org