You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2016/03/27 18:41:54 UTC
[compress] progress monitoring
Hi all
https://issues.apache.org/jira/browse/COMPRESS-207 asks for progress
tracking inside BZip2CompressorInputStream. As such I think the request
is to narrow (why add it for bzip2 but not gzip2?) and I created the
branch COMPRESS-207 for a prototypical implementation. This is
incomplete since I only really added support for bzip2 and only on the
reading side[1].
Is this a feature we generally want to see in compress? And if so, does
the branch make sense or should we tackle this in a different way?
Stefan
[1] right now CompressorOutputStreams don't even provide the number of
bytes written.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] progress monitoring
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-03-28, Emmanuel Bourg wrote:
> Le 27/03/2016 18:41, Stefan Bodewig a écrit :
>> Is this a feature we generally want to see in compress? And if so, does
>> the branch make sense or should we tackle this in a different way?
> I like the idea of progress tracking, and the implementation on the
> branch is ok (I'd just add a try-catch around the calls to notify(), so
> an error in a listener doesn't prevent the others from getting the
> notification).
Good catch, thanks.
> That said, maybe the concept of progress tracking is more general than
> [compress] and could be implemented as a decorator stream in [io]
Maybe in addition what I've done since right now notification would
happen at format specific events like starting a new block - this is
something the underlying stream doesn't recognize.
> (along with an approximation of the time left to process the stream).
Hard to say when a stream doesn't know how much data is waiting to get
processed :-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] progress monitoring
Posted by Gary Gregory <ga...@gmail.com>.
I've had progress streams and writers laying around for a long time. I'll
have to take the time to donate them to [io]...
Gary
On Mon, Mar 28, 2016 at 6:24 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 27/03/2016 18:41, Stefan Bodewig a écrit :
>
> > Is this a feature we generally want to see in compress? And if so, does
> > the branch make sense or should we tackle this in a different way?
>
> I like the idea of progress tracking, and the implementation on the
> branch is ok (I'd just add a try-catch around the calls to notify(), so
> an error in a listener doesn't prevent the others from getting the
> notification).
>
> That said, maybe the concept of progress tracking is more general than
> [compress] and could be implemented as a decorator stream in [io] (along
> with an approximation of the time left to process the stream).
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [compress] progress monitoring
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 27/03/2016 18:41, Stefan Bodewig a écrit :
> Is this a feature we generally want to see in compress? And if so, does
> the branch make sense or should we tackle this in a different way?
I like the idea of progress tracking, and the implementation on the
branch is ok (I'd just add a try-catch around the calls to notify(), so
an error in a listener doesn't prevent the others from getting the
notification).
That said, maybe the concept of progress tracking is more general than
[compress] and could be implemented as a decorator stream in [io] (along
with an approximation of the time left to process the stream).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org