commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Date Fri, 14 May 2010 07:27:36 GMT
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.


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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message