commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Date Fri, 14 May 2010 09:02:44 GMT
On 14/05/2010, Stefan Bodewig <bodewig@apache.org> wrote:
> On 2010-05-12, sebb <sebbaz@gmail.com> 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.

Yes, but the factory can pass in the name to the created stream.

>   * 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).

That would not be necessary if every IS that is created is given its
name via the ctor.

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

The base class could define an abstract method.
The only possible defaults would be empty Lists.
These would only be useful in the sense that subclasses would not need
to implement the methods.

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

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


Mime
View raw message