You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bg...@coyotesong.com on 2007/05/15 23:29:11 UTC
commons compress status?
I'm interested in merging some earlier archival work (in C) into commons
compress and would like to know who to coordinate with. The changes will
be... substantial... and I'll probably just fork the project for now, with
a goal of merging in late summer.
Also, what version of the JDK do projects use? Can we assume java5 yet?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Henri Yandell <fl...@gmail.com>.
On 5/16/07, Bear Giles <bg...@coyotesong.com> wrote:
> Torsten Curdt wrote:
> > On 15.05.2007, at 23:29, bgiles@coyotesong.com wrote:
> >
> >> I'm interested in merging some earlier archival work (in C) into commons
> >> compress and would like to know who to coordinate with. The changes
> >> will
> >> be... substantial... and I'll probably just fork the project for now,
> >> with
> >> a goal of merging in late summer.
> >
> > I was trying to add a new archiver implementation a few months ago.
> > Let's put it that way - substantial changes are good :)
> >
> > ...but I think leaving and just coming back with the new finished code
> > base is not really open-source'ish. If you want to attract some people
> > having discussions and incremental code contributions would be better.
> > (My 2 cents)
> As I recall somebody did a study of successful open source project and
> discovered a common element was a good seed implementation and only a
> few people with a strong, shared vision. Otherwise projects tended to
> get mired down in a grey ooze. Fortunately it's easy to figure out what
> a good seed would be in this case -- the interfaces and a few sample
> (and simple!) archive formats.
Getting from 0 to few is tradtionally the problem for compress :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Bear Giles <bg...@coyotesong.com>.
Torsten Curdt wrote:
> On 15.05.2007, at 23:29, bgiles@coyotesong.com wrote:
>
>> I'm interested in merging some earlier archival work (in C) into commons
>> compress and would like to know who to coordinate with. The changes
>> will
>> be... substantial... and I'll probably just fork the project for now,
>> with
>> a goal of merging in late summer.
>
> I was trying to add a new archiver implementation a few months ago.
> Let's put it that way - substantial changes are good :)
>
> ...but I think leaving and just coming back with the new finished code
> base is not really open-source'ish. If you want to attract some people
> having discussions and incremental code contributions would be better.
> (My 2 cents)
As I recall somebody did a study of successful open source project and
discovered a common element was a good seed implementation and only a
few people with a strong, shared vision. Otherwise projects tended to
get mired down in a grey ooze. Fortunately it's easy to figure out what
a good seed would be in this case -- the interfaces and a few sample
(and simple!) archive formats.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Torsten Curdt <tc...@apache.org>.
On 15.05.2007, at 23:29, bgiles@coyotesong.com wrote:
> I'm interested in merging some earlier archival work (in C) into
> commons
> compress and would like to know who to coordinate with. The
> changes will
> be... substantial... and I'll probably just fork the project for
> now, with
> a goal of merging in late summer.
I was trying to add a new archiver implementation a few months ago.
Let's put it that way - substantial changes are good :)
...but I think leaving and just coming back with the new finished
code base is not really open-source'ish. If you want to attract some
people having discussions and incremental code contributions would be
better. (My 2 cents)
> Also, what version of the JDK do projects use? Can we assume java5
> yet?
I would assume 1.4
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I agree that the 'compress' tar classes should be removed and a
> pointer left to the VFS project.
We've already moved an early version (before the api cleanup) of the
COMPRESS codebase to VFS.
The thing is, that VFS normally would NOT like to provide the
implementation for a certain filesystem, it should just be a wrapper for
the implementation library.
We can make an exception, though, fact is that there are too to few
active developers (yet) for VFS to push stuff like this any further.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 5/18/07, Torsten Curdt <tc...@apache.org> wrote:
> VFS is a filesystem abstraction layer. It may use the library ....but
> should not provide the implementation IMO.
+1, compression is a rather important topic in itself.
--
My cats know that I am a loser who goes out for hunting every day
without ever returning as much as a single mouse. Fortunately, I've
got a wife who's a real champ: She leaves the house and returns within
half an hour, carrying whole bags full of meal.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Torsten Curdt <tc...@apache.org>.
On 18.05.2007, at 19:17, Bear Giles wrote:
> Torsten Curdt wrote:
>> Hm... seems like I disagree here. I want a simple library that
>> deals with common compression and archive formats
>>
>> - tar
>> - ar
>> - cpio
>> - gzip
>> - bzip2
>> - zip
>>
>> VFS is a filesystem abstraction layer. It may use the
>> library ....but should not provide the implementation IMO.
> Compression and archive are really only related by a USES
> relationship and there's no reason why they -have- to remain in the
> same package.
But they are so often used in the same context that I would argue
it's a not worth splitting this up into separate libraries.
Especially as the JDK already provides the basic implementations of
some of the compressors.
> CAB (windows) is an additional format,
sure ...let's add it :)
> and you can make an argument for the Debian and Red Hat package
> formats as well.
Debian is using ar and tgz. Just the structure of the archive makes
it a Debian package. Not exactly sure about RPMs.
...but where is your point? I am not saying we can't add other
implementations. Only that a separation would be a bit artificial.
Plus the two things have to work together very well from the API
point of view. Having this in one library would make sure that this
is the case.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Bear Giles <bg...@coyotesong.com>.
Torsten Curdt wrote:
> Hm... seems like I disagree here. I want a simple library that deals
> with common compression and archive formats
>
> - tar
> - ar
> - cpio
> - gzip
> - bzip2
> - zip
>
> VFS is a filesystem abstraction layer. It may use the library ....but
> should not provide the implementation IMO.
Compression and archive are really only related by a USES relationship
and there's no reason why they -have- to remain in the same package.
CAB (windows) is an additional format, and you can make an argument for
the Debian and Red Hat package formats as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Torsten Curdt <tc...@apache.org>.
On 18.05.2007, at 05:13, Bear Giles wrote:
> Thorbjørn Ravn Andersen wrote:
>> I therefore suggest that the tar methods should be migrated to the
>> vfs module (if suitable) and that the compress module should
>> contain methods that can compress/uncompress streams (which is
>> easily extendable to files, http connections etc).
>>
>> By doing so there will be a clear goal of this project.
> It looks like VFS has most of the concepts I was working on so it
> would be a waste of effort to do a parallel effort. I had skimmed
> the project earlier but only noticed the networked implementations.
>
> I agree that the 'compress' tar classes should be removed and a
> pointer left to the VFS project.
Hm... seems like I disagree here. I want a simple library that deals
with common compression and archive formats
- tar
- ar
- cpio
- gzip
- bzip2
- zip
VFS is a filesystem abstraction layer. It may use the library ....but
should not provide the implementation IMO.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Bear Giles <bg...@coyotesong.com>.
Thorbjørn Ravn Andersen wrote:
> I therefore suggest that the tar methods should be migrated to the vfs
> module (if suitable) and that the compress module should contain
> methods that can compress/uncompress streams (which is easily
> extendable to files, http connections etc).
>
> By doing so there will be a clear goal of this project.
It looks like VFS has most of the concepts I was working on so it would
be a waste of effort to do a parallel effort. I had skimmed the project
earlier but only noticed the networked implementations.
I agree that the 'compress' tar classes should be removed and a pointer
left to the VFS project.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
bgiles@coyotesong.com skrev den 17-05-2007 00:20:
>
> You can't do that if you only see archives as boring things used in
> backups. Backups that are either windows (zip) or unix (tar), yawn.
>
> If you go hardcore, you'll notice that a lot of common file formats
> provide support for arbitrary data to be buried within the files. JPEG
> and PNG image formats, ELF executable files and shared libraries.... This
> definitely isn't 1.0 stuff, but it's something to keep in mind.
>
A brief look at the package shows that it would contain API's for tar
and bzip2. The first is an archiving format like zip, and the second a
compression method on a stream.
I therefore suggest that the tar methods should be migrated to the vfs
module (if suitable) and that the compress module should contain methods
that can compress/uncompress streams (which is easily extendable to
files, http connections etc).
By doing so there will be a clear goal of this project.
--
Thorbjørn
Re: commons compress status?
Posted by bg...@coyotesong.com.
> On 5/15/07, bgiles@coyotesong.com <bg...@coyotesong.com> wrote:
>> I'm interested in merging some earlier archival work (in C) into commons
>> compress and would like to know who to coordinate with. The changes
>> will
>> be... substantial... and I'll probably just fork the project for now,
>> with
>> a goal of merging in late summer.
>
> It's a dormant component at the moment (we need to move it over to
> dormant I think). I don't know of anyone who is monitoring it - Chris
> Grobmeier was the last one who was discussing working on it (or am I
> forgetting someone more recently?)
Hmmm... dormant....
Seriously, that creates a lot of flexibility. The cool thing about
archives is that you can think about them as persistent Maps if you're
willing to be see a "filename" as potentially an arbitrary string key
instead of just a concrete presentation of a concrete file on your hard
disk. That insight makes you look at archive files in a whole new light,
as something potentially occupying a space between a properties file and a
full JDBC connection. Something that can even be nested, e.g., the .deb
package format is nothing more than a couple compressed tar files inside
of a unix 'ar' library/archive.
You can't do that if you only see archives as boring things used in
backups. Backups that are either windows (zip) or unix (tar), yawn.
If you go hardcore, you'll notice that a lot of common file formats
provide support for arbitrary data to be buried within the files. JPEG
and PNG image formats, ELF executable files and shared libraries.... This
definitely isn't 1.0 stuff, but it's something to keep in mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons compress status?
Posted by Henri Yandell <fl...@gmail.com>.
On 5/15/07, bgiles@coyotesong.com <bg...@coyotesong.com> wrote:
> I'm interested in merging some earlier archival work (in C) into commons
> compress and would like to know who to coordinate with. The changes will
> be... substantial... and I'll probably just fork the project for now, with
> a goal of merging in late summer.
It's a dormant component at the moment (we need to move it over to
dormant I think). I don't know of anyone who is monitoring it - Chris
Grobmeier was the last one who was discussing working on it (or am I
forgetting someone more recently?)
> Also, what version of the JDK do projects use? Can we assume java5 yet?
Given compress has never released, I don't think it would be bad to
assume that.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org