You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2010/05/11 17:55:14 UTC
[COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Seems to me that it would be useful to be able to find out what
ArchiveInputStream has been chosen by the ArchiveStreamFactory.
I'm thinking of adding something like:
public String getArchiveType() {
return ArchiveStreamFactory.TAR ; // or ZIP etc.
}
to each of the AIS subclasses.
The AIS parent class could either have a dummy implementation, or the
parent method could be abstract to force subclasses to provide the
method.
The same could be done for CompressorStreamFactory.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by Torsten Curdt <tc...@vafer.org>.
>> IIUC you want the type of the archive, but we are dealing here with
>> Archiver implementations. In theory we could have 2 different
>> implementations for e.g. "zip".
>
> But they would both return "zip", which is what is wanted.
That is the question. They could as well also be
standard-zip
something-special-zip
We have 3 different kinds of "zip".
Implementation "zip" -> Archive Type "zip" -> File Exension "zip"
Now it depends on how we want to handle this at the factory level.
Right now we only have one implementation per archive type - with the
implementation names being the same as the types. So we still have the
luxury of making up our minds about this.
One thing that also crossed my mind was a possible relation to file
extensions and mime-types. Maybe it would make sense to have a
ArchiveType with meta information? I don't know. I might as well just
over analyzing this :)
Rant over and out.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by sebb <se...@gmail.com>.
On 11/05/2010, Torsten Curdt <tc...@vafer.org> wrote:
> >> That said: Is there a particular reason you need this? Or is this just
> >> because you think it might be useful?
> >
> > I was thinking it would be useful for the proposed command-line
> > utility - you could pass it any archive file and find out what it is.
>
>
> Hm ...all you would get is the implementation identifier for the
> factory, not the type of the archive.
Surely one would get the identifier for the Stream class?
> IIUC you want the type of the archive, but we are dealing here with
> Archiver implementations. In theory we could have 2 different
> implementations for e.g. "zip".
But they would both return "zip", which is what is wanted.
> See what I mean?
No, I don't.
> I am not really against it but I am not a fan either.
>
>
> > Also it would be useful for unit tests, to check that the correct type
> > has been detected.
>
>
> Uhm ... Unit test are the perfect place to use instance or class comparisons :)
>
> ...as we do currently
>
> final ArchiveInputStream tar = getStreamFor("bla.tar");
> assertNotNull(tar);
> assertTrue(tar instanceof TarArchiveInputStream);
>
> Since a simple HashMap could solve the task of reverse mapping for a
> real type lookup just fine - I would not add it ...but this is not a
> -1
Of course one can use a HashMap, but that would have to be updated for
every new implementation.
> cheers
> --
>
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by Torsten Curdt <tc...@vafer.org>.
>> That said: Is there a particular reason you need this? Or is this just
>> because you think it might be useful?
>
> I was thinking it would be useful for the proposed command-line
> utility - you could pass it any archive file and find out what it is.
Hm ...all you would get is the implementation identifier for the
factory, not the type of the archive.
IIUC you want the type of the archive, but we are dealing here with
Archiver implementations. In theory we could have 2 different
implementations for e.g. "zip".
See what I mean?
I am not really against it but I am not a fan either.
> Also it would be useful for unit tests, to check that the correct type
> has been detected.
Uhm ... Unit test are the perfect place to use instance or class comparisons :)
...as we do currently
final ArchiveInputStream tar = getStreamFor("bla.tar");
assertNotNull(tar);
assertTrue(tar instanceof TarArchiveInputStream);
Since a simple HashMap could solve the task of reverse mapping for a
real type lookup just fine - I would not add it ...but this is not a
-1
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by sebb <se...@gmail.com>.
On 11/05/2010, Torsten Curdt <tc...@vafer.org> wrote:
> In the code we call it "Archivername". That should be changed
> accordingly to "type" then IMO. (getArchiveName() could be a little
> ambiguous)
>
> That said: Is there a particular reason you need this? Or is this just
> because you think it might be useful?
I was thinking it would be useful for the proposed command-line
utility - you could pass it any archive file and find out what it is.
Also it would be useful for unit tests, to check that the correct type
has been detected.
[Yes, one check the class name, but that is a bit messy].
>
> On Tue, May 11, 2010 at 17:55, sebb <se...@gmail.com> wrote:
> > Seems to me that it would be useful to be able to find out what
> > ArchiveInputStream has been chosen by the ArchiveStreamFactory.
> >
> > I'm thinking of adding something like:
> >
> > public String getArchiveType() {
> > return ArchiveStreamFactory.TAR ; // or ZIP etc.
> > }
> >
> > to each of the AIS subclasses.
> >
> > The AIS parent class could either have a dummy implementation, or the
> > parent method could be abstract to force subclasses to provide the
> > method.
> >
> > The same could be done for CompressorStreamFactory.
> >
> > Thoughts?
> >
>
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Posted by Stefan Bodewig <bo...@apache.org>.
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 <se...@gmail.com> wrote:
> On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2010-05-14, sebb <se...@gmail.com> wrote:
>>> On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
>>>> On 2010-05-12, sebb <se...@gmail.com> 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 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.
>>>> 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 ...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by sebb <se...@gmail.com>.
On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-05-14, sebb <se...@gmail.com> wrote:
>
> > On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
> >> On 2010-05-12, sebb <se...@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.
>
>
> What if I don't create the stream via the factory?
Then the default name is used.
> To make this work all implementations would need a new constructor with
> an additional argument - that wouldn't make any sense for users who
> bypass the factory.
Only for classes that support multiple formats, but then the ctor
needs to be told which it is handling anyway.
> If this is the purpose of the method I'd prefer to see it inside the
> factory, some getArchiverNames(Class) or
> getArchiverNames(ArchiveInputStream) that returned an immutable list of
> strings.
>
> We could still put a method into ArchiveInputStream that queried the
> factory passing in itself.
>
>
> >> * 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.
>
>
> Assume one we have multiple names for one implementation. For example
> old_ascii, old_binary, new_portable and new_portable_crc for cpio since
> these really are different formats. If we use autodetection - which is
> why you want the method in the first place IIUC - then which name do you
> expect the factory to pass into said constructor?
cpio + old_ascii etc (see below).
> 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.
Only the factory currently knows which version of a format is being
used, because the matching is performed in the factory code. And that
information is currently lost once the input stream has been created.
If we do wish the IS classes to validate the format, then the classes
will need to be created accordingly, and can therefore return their
specific format.
But I think a class that processes various versions of cpio should
return "cpio" as its fundamental type; it may also return "old_ascii"
etc as the version of the type.
> So if this is the purpose of the new method then it has to live inside
> the implementation and I don't see which default implementation could
> make sense.
Apart from Zip/Jar, all the current classes only support a single type.
> >>> 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.
>
>
> That's what I was trying to say - the default of an empty list is not
> reasonable ("it simply doesn't make sense" in case I'm just using the
> wrong English word for what I mean).
We could define empty list to mean "unknown".
>
> 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
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-05-14, sebb <se...@gmail.com> wrote:
> On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2010-05-12, sebb <se...@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.
What if I don't create the stream via the factory?
To make this work all implementations would need a new constructor with
an additional argument - that wouldn't make any sense for users who
bypass the factory.
If this is the purpose of the method I'd prefer to see it inside the
factory, some getArchiverNames(Class) or
getArchiverNames(ArchiveInputStream) that returned an immutable list of
strings.
We could still put a method into ArchiveInputStream that queried the
factory passing in itself.
>> * 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.
Assume one we have multiple names for one implementation. For example
old_ascii, old_binary, new_portable and new_portable_crc for cpio since
these really are different formats. If we use autodetection - which is
why you want the method in the first place IIUC - then which name do you
expect the factory to pass into said constructor?
Only the implementation knows the real format it has detected.
So if this is the purpose of the new method then it has to live inside
the implementation and I don't see which default implementation could
make sense.
>>> 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.
That's what I was trying to say - the default of an empty list is not
reasonable ("it simply doesn't make sense" in case I'm just using the
wrong English word for what I mean).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by sebb <se...@gmail.com>.
On 14/05/2010, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-05-12, sebb <se...@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
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream classes?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-05-12, sebb <se...@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.
* 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
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by sebb <se...@gmail.com>.
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 <tc...@vafer.org> wrote:
> So far it's only local variables and documentation ;) ...unless I
> missed something.
>
>
> On Wed, May 12, 2010 at 07:53, Christian Grobmeier <gr...@gmail.com> wrote:
> > On Tue, May 11, 2010 at 9:04 PM, Torsten Curdt <tc...@vafer.org> 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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by Torsten Curdt <tc...@vafer.org>.
So far it's only local variables and documentation ;) ...unless I
missed something.
On Wed, May 12, 2010 at 07:53, Christian Grobmeier <gr...@gmail.com> wrote:
> On Tue, May 11, 2010 at 9:04 PM, Torsten Curdt <tc...@vafer.org> 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: 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
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, May 11, 2010 at 9:04 PM, Torsten Curdt <tc...@vafer.org> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Add getArchiveType() method to [Archive|Compressor]InputStream
classes?
Posted by Torsten Curdt <tc...@vafer.org>.
In the code we call it "Archivername". That should be changed
accordingly to "type" then IMO. (getArchiveName() could be a little
ambiguous)
That said: Is there a particular reason you need this? Or is this just
because you think it might be useful?
On Tue, May 11, 2010 at 17:55, sebb <se...@gmail.com> wrote:
> Seems to me that it would be useful to be able to find out what
> ArchiveInputStream has been chosen by the ArchiveStreamFactory.
>
> I'm thinking of adding something like:
>
> public String getArchiveType() {
> return ArchiveStreamFactory.TAR ; // or ZIP etc.
> }
>
> to each of the AIS subclasses.
>
> The AIS parent class could either have a dummy implementation, or the
> parent method could be abstract to force subclasses to provide the
> method.
>
> The same could be done for CompressorStreamFactory.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> 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