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 13:36:52 GMT
So for I don't think we are really in any sort of disagreement, so we
should be able to cut this thread soon 8-)

On 2010-05-14, sebb <> wrote:

> On 14/05/2010, Stefan Bodewig <> wrote:
>> On 2010-05-14, sebb <> wrote:

>>> On 14/05/2010, Stefan Bodewig <> wrote:
>>>> On 2010-05-12, sebb <> wrote:

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

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

In this case I stick with my opinion that it should be part of the
factory and it should return a list for each implementation.  OTOH I
don't think this is the information you really won't but rather:

>>>>   * The format of the current stream?

In this case the method should be in ArchiveInputStream and should be
abstract IMHO.

>>  Only the implementation knows the real format it has detected.

> At present, the implementations *don't* actually know, as they all
> process format differences on the fly -. they don't check that the
> same format is being used throught the file and each record may have
> different settings so long as these are self-consistent.
> This is perhaps a bug.

Not sure about cpio but for it is rather common to encode to different
formats within the same archive.  The same would be true for zip/zip64
where an entry that fits into the old header format would use it any
only files that require zip64 features use the new format.

In this case there really isn't *the* format of a stream if we wanted to
split it further.  And we'd likely end up returning "tar" or "zip" from
the method you want anyway.  So my example of different format dialects
turns out to be a red herring.

> Only the factory currently knows which version of a format is being
> used, because the matching is performed in the factory code.

... by delegating to various signature sniffing methods in the stream
classes ...


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

View raw message