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 2014/01/27 11:28:34 UTC
[io][compress] Interest in Some Channel Classes?
Hi
while pondering the API of Compress 2.x I already moaned about the lack
of decorator support in Channels, in particular pushback would be needed
in Compress in many places, but also stuff like counting, verifying
checksums and other Filter*Stream stuff.
When I started to look around I didn't find anything inside IO (which
came as a suprise) but I stumbled over
http://sourceforge.net/p/mcpkutil/trunk/ci/master/tree/src/cxlarchive/util/Bytes.java
which has filtering for channels. It is not a lot of code but could be
a useful seed. I contacted Gregory Janik, the author of mcpkutil and
he'd be fine with us forking the code.
Any interest for IO? I'd likely take that path for Compress2 anyway.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io][compress] Interest in Some Channel Classes?
Posted by sebb <se...@gmail.com>.
On 27 January 2014 18:31, Gary Gregory <ga...@gmail.com> wrote:
> Bleh, just make [compress] depend on [io], nice and simple.
Agreed.
> Gary
>
>
> On Mon, Jan 27, 2014 at 1:01 PM, Matt Benson <gu...@gmail.com> wrote:
>
>> +1... this seems to be the best approach for independent components without
>> code duplication.
>>
>> Matt
>>
>>
>> On Mon, Jan 27, 2014 at 11:50 AM, Torsten Curdt <tc...@vafer.org> wrote:
>>
>> > > The current [compress] codebase has already copied bigger chunks of
>> > > IOUtils and some stream classes from [io]. Whether we intend to keep
>> > > copying stuff around for [compress2] or simply make [io] a dependency
>> is
>> > > something I see as a separate issue. One that wants to get addressed,
>> > > though.
>> >
>> > I vote for a hidden dependency (automatically inlining only the needed
>> > classes in a different namespace at build time with the maven shade
>> > plugin)
>> >
>> > cheers,
>> > Torsten
>> >
>> > ---------------------------------------------------------------------
>> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io][compress] Interest in Some Channel Classes?
Posted by Gary Gregory <ga...@gmail.com>.
Bleh, just make [compress] depend on [io], nice and simple.
Gary
On Mon, Jan 27, 2014 at 1:01 PM, Matt Benson <gu...@gmail.com> wrote:
> +1... this seems to be the best approach for independent components without
> code duplication.
>
> Matt
>
>
> On Mon, Jan 27, 2014 at 11:50 AM, Torsten Curdt <tc...@vafer.org> wrote:
>
> > > The current [compress] codebase has already copied bigger chunks of
> > > IOUtils and some stream classes from [io]. Whether we intend to keep
> > > copying stuff around for [compress2] or simply make [io] a dependency
> is
> > > something I see as a separate issue. One that wants to get addressed,
> > > though.
> >
> > I vote for a hidden dependency (automatically inlining only the needed
> > classes in a different namespace at build time with the maven shade
> > plugin)
> >
> > cheers,
> > Torsten
> >
> > ---------------------------------------------------------------------
> > 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: [io][compress] Interest in Some Channel Classes?
Posted by Matt Benson <gu...@gmail.com>.
+1... this seems to be the best approach for independent components without
code duplication.
Matt
On Mon, Jan 27, 2014 at 11:50 AM, Torsten Curdt <tc...@vafer.org> wrote:
> > The current [compress] codebase has already copied bigger chunks of
> > IOUtils and some stream classes from [io]. Whether we intend to keep
> > copying stuff around for [compress2] or simply make [io] a dependency is
> > something I see as a separate issue. One that wants to get addressed,
> > though.
>
> I vote for a hidden dependency (automatically inlining only the needed
> classes in a different namespace at build time with the maven shade
> plugin)
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [io][compress] Interest in Some Channel Classes?
Posted by Torsten Curdt <tc...@vafer.org>.
> The current [compress] codebase has already copied bigger chunks of
> IOUtils and some stream classes from [io]. Whether we intend to keep
> copying stuff around for [compress2] or simply make [io] a dependency is
> something I see as a separate issue. One that wants to get addressed,
> though.
I vote for a hidden dependency (automatically inlining only the needed
classes in a different namespace at build time with the maven shade
plugin)
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io][compress] Interest in Some Channel Classes?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-01-27, Benedikt Ritter wrote:
> I've planned to do some work on IO after [lang] 3.3, but you know how
> it often turn's out with my plans ;-) so I cannot promise anything.
tell me - I'll go MIA for most of the next two or three weeks, I'm
afraid.
> One thing I don't understand is: are you suggesting to put the Bytes class
> into [io] and then define a dependency from [compress] to [io]? Maybe there
> is more that can be moved from [compress] to [io]?
First of all I'd likely create a channels package in [io] and turn all
those inner classes into top-level ones, but apart from the details,
yes, that's the idea.
The current [compress] codebase has already copied bigger chunks of
IOUtils and some stream classes from [io]. Whether we intend to keep
copying stuff around for [compress2] or simply make [io] a dependency is
something I see as a separate issue. One that wants to get addressed,
though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io][compress] Interest in Some Channel Classes?
Posted by Benedikt Ritter <br...@apache.org>.
Hi Stefan,
getting some steam back into [io] is a good idea. Has been some time since
I've seen the last commit there. If the Bytes class is a useful addition to
[io] and Gregory Janik is okay with a fork, than go ahead!
I've planned to do some work on IO after [lang] 3.3, but you know how it
often turn's out with my plans ;-) so I cannot promise anything.
One thing I don't understand is: are you suggesting to put the Bytes class
into [io] and then define a dependency from [compress] to [io]? Maybe there
is more that can be moved from [compress] to [io]?
Regards,
Benedikt
2014/1/27 Stefan Bodewig <bo...@apache.org>
> Hi
>
> while pondering the API of Compress 2.x I already moaned about the lack
> of decorator support in Channels, in particular pushback would be needed
> in Compress in many places, but also stuff like counting, verifying
> checksums and other Filter*Stream stuff.
>
> When I started to look around I didn't find anything inside IO (which
> came as a suprise) but I stumbled over
>
> http://sourceforge.net/p/mcpkutil/trunk/ci/master/tree/src/cxlarchive/util/Bytes.java
> which has filtering for channels. It is not a lot of code but could be
> a useful seed. I contacted Gregory Janik, the author of mcpkutil and
> he'd be fine with us forking the code.
>
> Any interest for IO? I'd likely take that path for Compress2 anyway.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter