Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <449FF39B.90400@possessed.de>
Date: Mon, 26 Jun 2006 16:47:55 +0200
From: "C. Grobmeier" <grobmeier@possessed.de>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [compress] Draft 8
References: <449FD28B.30806@possessed.de> <449FEBDA.8090307@ops.co.at>
In-Reply-To: <449FEBDA.8090307@ops.co.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----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