You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "C. Grobmeier" <gr...@possessed.de> on 2006/06/26 14:26:51 UTC

[compress] Draft 8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

here is draft 8:
* http://grobmeier.de/commons-compress-draft-8.zip

I mainly have rebuild the factorys:
- - Archiver is now know as Archive
- - reduced reflection-magic
- - Decompressor and Compressor is now know as Compressor (just one factory)
- - some moves here an there

I have to review comments, docs and if all methods a right in place, but
that's the direction i like (at the moment ;-))

Please let me know what you think.
Regards,
Chris

- --
Christian Grobmeier
Possessed Management
Hurlacher Str. 5 - 86853 Langerringen - Germany
E-Mail: grobmeier@possessed.de
Mobil: +(49)(0)175 57 66830
Fax: +(49) (0)8232 959119
Web: http://www.possessed.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn9KLkv8rKBUE/T4RAs2dAKCOX3Lpzpuzn7V5rSudTJ4+iXFo1gCcCg1G
Kjlzfk4ULmO4nsO9yKW7QMU=
=D/rF
-----END PGP SIGNATURE-----

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


Re: [compress] Draft 8

Posted by "C. Grobmeier" <gr...@possessed.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Great :-)
I am eager to do this delete stuff on top of this.

- - Chris

Torsten Curdt wrote:
>> The grants has been received by Jim. I've merged the changes from
>> Chris into my working copy of compress ...any objections to do a "svn
>> commit" ? :-)
> 
> Ok I will go ahead and commit it then :)
> 
> cheers
> -- 
> Torsten
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEzeLgkv8rKBUE/T4RAn8HAJ9u6kYi06o47y8EvYX7nTvkugepyQCfYU89
h22qHIZ93+9vAYGpKu3nVjw=
=ERsT
-----END PGP SIGNATURE-----

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


Re: Re: Re: [compress] Draft 8

Posted by Torsten Curdt <tc...@apache.org>.
> The grants has been received by Jim. I've merged the changes from
> Chris into my working copy of compress ...any objections to do a "svn
> commit" ? :-)

Ok I will go ahead and commit it then :)

cheers
--
Torsten

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


Re: Re: [compress] Draft 8

Posted by Torsten Curdt <tc...@apache.org>.
The grants has been received by Jim. I've merged the changes from
Chris into my working copy of compress ...any objections to do a "svn
commit" ? :-)
cheers
--
Torsten

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


Re: [compress] Draft 8

Posted by "C. Grobmeier" <gr...@possessed.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> Some comments:
> * you use File*Streams instead of simply InputStream/OutputStream, any
> reason for this?If no, please change it accordingly.

sorry, thought i changed that allready. I will do so

> * simplify the archiver interface. e.g. I think methods like save(File)
> are useless and we can put it in an utility class if wanted.

unsure about this. Personally i find it to simply to say: store it here.
BUt on the otherhand, less methods sound great too.

> * Also I think we can drop things like add(File) when we can do the same
> with add(ArchiveEntry)

Ok, we could do that yes. Same as above: someone always has to instance
an ArchiveEntry instead of just dropping a file there. This makes the
api easier- but does this make it comfortable?

> ** If you would like to, we can can use something like
> *** ArchiveEntryFactory.create(File) - returns a FileArchiveEntry
> *** ArchiveEntryFactory.create(name, inputStream) - returns a
> StreamArchiveEntry

Another factory? Why not using: new ArchiveEntry(name, inputStream)?

> * for VFS it would be nice to have methods like Archive.list() to get a
> list of all entries in the current archive

OK :-)

> * said that we should rename the method getEntryIterator to
> getPendingOperations (also prepare the internal list for things like delete)

getPendingOperations sounds good, but in this list are not always
pending operations. It also reflects whats allready in there. Is
pendingoperations a good term for this now? My english is a bit buggy i
believe what you are saying ;-)

> * the same for the Compressor interface. I think we should drop the
> duplicated API - remove all the File stuff and change File*Stream to
> InputStream/OutputStream. This makes the stuff much simpler.
> In AbstractCompressor you create temp-files. When removing the File
> stuff we can get rid of it.

Ah, thats a good reason fo getting rid of this methods. Now i am quite
sure i'd like to delete the file stuff.

 If you still would like to have such methods
> move them to a CompressorUtils class - and consider using Piped streams,
> then you do not have to deal with temp files no one might ever cleanup -
> trust me, in VFS I have such a problem too.

OK, i'll keep that in mind.
> 
> I hope I didnt miss anything from the previous discussions which states
> that you do all the things above, just give me a pointer if this is the
> case.

Thank you for your comments. Within the last 8 drafts this small
interface has been grown better and better. 1 or 2 drafts more and its a
pretty piece of code, imho.

Chris

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn/Obkv8rKBUE/T4RAhe4AKCOD21wZSOcqsgfwv2RB6tPpXhLAwCeLDaD
M/j2GQ01g/EwX2LkeLN2tpI=
=Tcdo
-----END PGP SIGNATURE-----

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


Re: [compress] Draft 8

Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi !
> here is draft 8:
Great, thanks!

Some comments:
* you use File*Streams instead of simply InputStream/OutputStream, any
reason for this?If no, please change it accordingly.
* simplify the archiver interface. e.g. I think methods like save(File)
are useless and we can put it in an utility class if wanted.
* Also I think we can drop things like add(File) when we can do the same
with add(ArchiveEntry)
** If you would like to, we can can use something like
*** ArchiveEntryFactory.create(File) - returns a FileArchiveEntry
*** ArchiveEntryFactory.create(name, inputStream) - returns a
StreamArchiveEntry
* for VFS it would be nice to have methods like Archive.list() to get a
list of all entries in the current archive
* said that we should rename the method getEntryIterator to
getPendingOperations (also prepare the internal list for things like delete)

* the same for the Compressor interface. I think we should drop the
duplicated API - remove all the File stuff and change File*Stream to
InputStream/OutputStream. This makes the stuff much simpler.
In AbstractCompressor you create temp-files. When removing the File
stuff we can get rid of it. If you still would like to have such methods
move them to a CompressorUtils class - and consider using Piped streams,
then you do not have to deal with temp files no one might ever cleanup -
trust me, in VFS I have such a problem too.

I hope I didnt miss anything from the previous discussions which states
that you do all the things above, just give me a pointer if this is the
case.


Ciao,
Mario


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