commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dakota Jack" <dakota.j...@gmail.com>
Subject Re: I wrote several methods for IOCommons FileUtil. How can I donate it to IOCommons?
Date Mon, 19 Jun 2006 02:44:02 GMT
Having compression apart from IO is really questionable.  What would
compression be for if not for IO?  Whomever made the decision to set
compression aside from IO has made a grave error that will create
complications like this until someone with more sense gets the say.

On 6/18/06, Martin Cooper <martinc@apache.org> wrote:
> On 6/18/06, Vitaliy S <runawfe@gmail.com> wrote:
> >
> > re:but AFAIK zip and jar share the same compression algorithm anyway.
> >
> > The algorithms are similar but not the same.
> >
> > re:...and then add a methods for bzip2, compress and gzip, too? See where
> > I
> > am heading? Better let's have a CompressUtils in compress.
> >
> > Compress doesn't work with files while IO does. On the other hand IO
> > doesn't
> > work with compression while Compress does ;-)
> > I think it would be good idea to add compress to IO :-)
>
>
> I agree with Torsten that what you are suggesting would be a better fit for
> the Compress component. The way I look at it is that IO is a more general
> purpose library, and handling compression is more specialised. Once we start
> adding specialised functionality to IO, where would we draw the line? It
> would quickly become bloated and unwieldy. Better to keep specialised
> functionality in a component focussed on that specialisation.
>
> --
> Martin Cooper
>
>
> IMHO My codes fits better IO (I took the idea from IO source code).
> > But if the community won't reject I'll post a patch to IO.
> >
> > Regards,
> > Vitaliy S
> >
> >
> > On 6/18/06, Torsten Curdt <tcurdt@apache.org> wrote:
> > >
> > > > re: http://jakarta.apache.org/commons/sandbox/compress/
> > > > Thanks for a link, but my code couldn't be applied to compress.
> > Compress
> > > > does nothing with jar.
> > >
> > > Doesn't mean that could not be changed ;-)
> > >
> > > ...but AFAIK zip and jar share the same compression algorithm anyway.
> > > So why the two methods? (Did I miss something?)
> > >
> > > > re:IMO compression is beyond the scope of IO.
> > > > Consider this example from
> > > > http://weblogs.java.net/blog/kgh/archive/2005/11/my_favorite_dea.html
> > >
> > > <snip/>
> > >
> > > > To me apache commons is a set of projects that provide short cuts for
> > > common
> > > > things.
> > > > Of course we all like clean disgin, but I like "clean design" unless
> > it
> > > > doesn't make me to write 20 lines of code to simply zip or jar the
> > > folder
> > > > (same goes for file reading).
> > >
> > > I agree. All I am saying is that it should probably better go into the
> > > compress component.
> > >
> > > > IO Commons provides means to read file into byte array, why not to add
> > a
> > > > method to read a file or dir as compressed byte array too?
> > >
> > > ...and then add a methods for bzip2, compress and gzip, too? See where
> > > I am heading? Better let's have a CompressUtils in compress.
> > >
> > > WDYT?
> > >
> > > cheers
> > > --
> > > Torsten
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Vitaliy S
> >
> >
>
>


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message