You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Samuel Le Berrigaud <sa...@gmail.com> on 2008/07/06 04:35:49 UTC
Compress vs. VFS
Hi,
I was wondering about VFS vs. Compress.
I was looking at a library to handle zip files (mostly read) and came
across commons compress in the sandbox. I also made my way to VFS.
The latter seems to do as much as the "compress" component and even
more. Another good point of VFS is that it doesn't bring any other
dependencies (which is the same for compress).
How do commons developers see the 2 libraries evolving next to each other?
Is there any plan to get "compress" to a proper common project any time soon?
Or is most of the effort going to VFS and one should probably not
consider "compress" at all?
What do you guys see being the big difference between the 2 approaches
and is that a good enough reason to keep both libraries?
Thanks,
Samuel Le Berrigaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: Compress vs. VFS
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
Hello Christian,
many thanks, that's very interesting information indeed.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Christian Grobmeier [mailto:grobmeier@gmail.com]
> Sent: Monday, July 07, 2008 2:18 PM
> To: Commons Developers List
> Subject: Re: Compress vs. VFS
>
> Hi Martin,
> we would like to have an own apache component,
> cause several people here do not like the api.
> As stated in the board report of september 07,
> they is less community behind truezip, which is another -.
> However, if interested, check these discussions here:
> http://markmail.org/search/?q=TrueZip%20list%3Aorg.apache.comm
> ons.dev%2F
>
> There was also a discussion about a TrueZip provider for VFS,
> but i don't mind if that happened.
> See: http://issues.apache.org/jira/browse/VFS-106
>
> Best,
> Chris
>
> On Mon, Jul 7, 2008 at 11:34 AM, Oberhuber, Martin <
> Martin.Oberhuber@windriver.com> wrote:
>
> > Hello Samuel, Mario and others,
> >
> > if just interested in accessing ZIP files, have you
> > had a look at TrueZip:
> > https://truezip.dev.java.net/
> >
> > It might make sense to provide a TrueZip wrapper for
> > Commons VFS eventually.
> >
> > How do the Commons Compress folk compare to TrueZip?
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Compress vs. VFS
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi Martin,
we would like to have an own apache component,
cause several people here do not like the api.
As stated in the board report of september 07,
they is less community behind truezip, which is another -.
However, if interested, check these discussions here:
http://markmail.org/search/?q=TrueZip%20list%3Aorg.apache.commons.dev%2F
There was also a discussion about a TrueZip provider for VFS,
but i don't mind if that happened.
See: http://issues.apache.org/jira/browse/VFS-106
Best,
Chris
On Mon, Jul 7, 2008 at 11:34 AM, Oberhuber, Martin <
Martin.Oberhuber@windriver.com> wrote:
> Hello Samuel, Mario and others,
>
> if just interested in accessing ZIP files, have you
> had a look at TrueZip:
> https://truezip.dev.java.net/
>
> It might make sense to provide a TrueZip wrapper for
> Commons VFS eventually.
>
> How do the Commons Compress folk compare to TrueZip?
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
RE: Compress vs. VFS
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
Hello Samuel, Mario and others,
if just interested in accessing ZIP files, have you
had a look at TrueZip:
https://truezip.dev.java.net/
It might make sense to provide a TrueZip wrapper for
Commons VFS eventually.
How do the Commons Compress folk compare to TrueZip?
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Compress vs. VFS
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi Samuel,
>
> * I see that the
> Archive<
> http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html
> >
> interface and the
> ArchiverFactory<
> http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/ArchiverFactory.html
> >
> deal a lot with files.
> Wouldn't it be better for those APIs to only (mostly) rely on I/O
> streams? I believe the API shouldn't assume that a file system is
> available (when it makes sense). To cite one of my colleagues "files
> are evil" ;-) For example, I have a particular use case where I would
> like to extract a zip file from a within a war file. I obviously can't
> rely on files being available as nothing tells me whether the war is
> deployed exploded or not. Getting a stream to the given zip file
> however wouldn't be an issue?
> What do you think?
>
> * The Archive interface has the
> "getEntryIterator"<
> http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html#getEntryIterator()<http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html#getEntryIterator%28%29>
> >
> method. However this method will not iterate through entries of an
> existing archive but only through added entries. I believe this should
> somehow allow me to iterate through all entries, existing and added.
> Again what do you think?
we allready thought about that too and started to redesign that api.
You can take a look at the new api with GIT here:
http://projects.grobmeier.de/compress-redesign.git/
This API only uses streams at the moment. Later it may be discussed to
add the filebased classes as some kind of a helper somewhere.
If so, it's worth to think about your getEntryIterator idea. I will take it
on
my TODO list :-)
Best regards and thanks for you comments,
Chris.
Re: Compress vs. VFS
Posted by Samuel Le Berrigaud <sa...@gmail.com>.
Hi Mario,
thanks for the reply.
I now have a better understanding of the relationship between those 2.
And I believe it does make sense :-)
A couple of questions regarding the compress APIs though. Please, let
me know if you guys would rather I create Jira issues for those.
* I see that the
Archive<http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html>
interface and the
ArchiverFactory<http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/ArchiverFactory.html>
deal a lot with files.
Wouldn't it be better for those APIs to only (mostly) rely on I/O
streams? I believe the API shouldn't assume that a file system is
available (when it makes sense). To cite one of my colleagues "files
are evil" ;-) For example, I have a particular use case where I would
like to extract a zip file from a within a war file. I obviously can't
rely on files being available as nothing tells me whether the war is
deployed exploded or not. Getting a stream to the given zip file
however wouldn't be an issue?
What do you think?
* The Archive interface has the
"getEntryIterator"<http://commons.apache.org/sandbox/compress/apidocs/org/apache/commons/compress/Archive.html#getEntryIterator()>
method. However this method will not iterate through entries of an
existing archive but only through added entries. I believe this should
somehow allow me to iterate through all entries, existing and added.
Again what do you think?
Thanks,
SaM
On Sun, Jul 6, 2008 at 2:23 PM, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
>> What do you guys see being the big difference between the 2 approaches
>> and is that a good enough reason to keep both libraries?
>>
>
> VFS contains an old snapshot of compress just to being able to cut a
> release.
>
> Actually, compress is slowly evolving, once this has been finished we will
> remove that snapshot and have VFS depend on compress again, as it was
> before.
>
> VFS allows you e.g. to access a specific file within a compressed archive on
> an ftp server. All by just using a specific URL.
> It abstracts various different access methods an archives like ssh, smb,
> ftp, zip, bz2, tar etc.
>
> But, with compress as exception, it does not itself provide any
> implementation, vfs depends on various libraries for this and wrap them with
> the same api.
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Samuel Le Berrigaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Compress vs. VFS
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> What do you guys see being the big difference between the 2 approaches
> and is that a good enough reason to keep both libraries?
>
VFS contains an old snapshot of compress just to being able to cut a
release.
Actually, compress is slowly evolving, once this has been finished we
will remove that snapshot and have VFS depend on compress again, as it
was before.
VFS allows you e.g. to access a specific file within a compressed
archive on an ftp server. All by just using a specific URL.
It abstracts various different access methods an archives like ssh, smb,
ftp, zip, bz2, tar etc.
But, with compress as exception, it does not itself provide any
implementation, vfs depends on various libraries for this and wrap them
with the same api.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org