Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 75995 invoked from network); 14 May 2010 07:28:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 May 2010 07:28:12 -0000 Received: (qmail 36390 invoked by uid 500); 14 May 2010 07:28:12 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 36103 invoked by uid 500); 14 May 2010 07:28:10 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 35884 invoked by uid 99); 14 May 2010 07:28:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 May 2010 07:28:09 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [88.84.128.168] (HELO samaflost.de) (88.84.128.168) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 May 2010 07:28:01 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by samaflost.de (Postfix) with ESMTP id DD46828985D2 for ; Fri, 14 May 2010 09:27:40 +0200 (CEST) Received: from samaflost.de ([127.0.0.1]) by localhost (v35516.1blu.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdmCkkhCjmCN for ; Fri, 14 May 2010 09:27:39 +0200 (CEST) Received: by samaflost.de (Postfix, from userid 1000) id 21BEA28985D3; Fri, 14 May 2010 09:27:37 +0200 (CEST) From: Stefan Bodewig To: dev@commons.apache.org Subject: Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes? References: X-Draft-From: ("nnfolder:mail.jakarta-lib" 142816) Date: Fri, 14 May 2010 09:27:36 +0200 In-Reply-To: (sebb's message of "Wed, 12 May 2010 17:01:55 +0100") Message-ID: <87eihfrlhz.fsf@v35516.1blu.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked by ClamAV on apache.org On 2010-05-12, sebb wrote: > Can we restart this? > Compress currently has Archiver and Compressor InputStreamFactory > classes which have the following signatures: > public ArchiveInputStream createArchiveInputStream( > final String archiverName, final InputStream in) > public CompressorInputStream createCompressorInputStream(final String name, > final InputStream in) > The archiverName or name parameters are used to determine which stream > class to create, and should use one of the provided public constants. > I just want to provide the inverse conversion, i.e. tag the created > class with the key that was used to create it, so that this can be > easily determined later e.g. if the autodetect mode is used. In theory the inverse is not unique - the same implementation could be used for several names. It may become true in practice if we'd choose to use different names for variants of archive types like pax, posixtar and gnutar for tar. I think it depends on what you want the method that returns the archive type/name (s) to reflect. * The archive names you could pass into the create methods to obtain an instance of the same stream class? Then the method actually should be inside the factory rather than the stream class since only the factory can know that for sure. * The format of the current stream? In that case there can't be any reasonable default (other than asking the factory and potentially getting back a list of names rather than a single one). > It might also be useful for the classes to provide access to their > associated mime type(s) and "usual" file extension(s). These should > both be read-only Lists. OK. This isn't anything the factory could do (unless we broaden its contract) nor the base class could provide a reasonable default for. > If we really want to distinguish different implementations of the same > archive type, then maybe we can add a "fullName" or "version" field, > as is done for the JSR-223 (javax..script) API. However I cannot see > why that would be necessary. I'm on the fence here. > I think the next steps are to decide: > 1) Is it OK to add this to the API? If so: See above, it depends on what the method is supposed to return IMHO. > 2) What method name should be used? ask the Ant community and they'll tell you I'm not good at chosing names. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org