commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Date Wed, 12 May 2010 16:01:55 GMT
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.

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.

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 think the next steps are to decide:

1) Is it OK to add this to the API? If so:
2) What method name should be used?
3) Should subclasses be forced to implement the methods, or should
there be a default? [I prefer the former]

On 12/05/2010, Torsten Curdt <> wrote:
> So far it's only local variables and documentation ;) ...unless I
>  missed something.
>  On Wed, May 12, 2010 at 07:53, Christian Grobmeier <> wrote:
>  > On Tue, May 11, 2010 at 9:04 PM, Torsten Curdt <> wrote:
>  >> In the code we call it "Archivername". That should be changed
>  >> accordingly to "type" then IMO. (getArchiveName() could be a little
>  >> ambiguous)
>  >>
>  >
>  > no objections against the type, but: really change? I was thinking on
>  > backwards compatibility
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail:
>  > For additional commands, e-mail:
>  >
>  >
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
>  For additional commands, e-mail:

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

View raw message