[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Comment Edited] (COMPRESS-390) Expose zip stream offset and size via API
From:       "Zbynek Vyskovsky (JIRA)" <jira () apache ! org>
Date:       2017-04-30 4:02:04
Message-ID: JIRA.13066921.1493176170000.86668.1493524924067 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=15990111#comment-15990111 ] \


Zbynek Vyskovsky edited comment on COMPRESS-390 at 4/30/17 4:01 AM:
--------------------------------------------------------------------

[~bodewig] No problem,I'm sorry about the delay, I haven't found time to go through \
it and to think about it into detail...

I see your last point, it would be solvable with Java 8 default methods but we still \
maintain Java 7 compatibility, so not an option here anyway.

About the previous comment - I'm just thinking about trade-off between perfect and \
never-lying solution and something which is still quite easy to use and is \
transparent across all the potential types of archives. One thing I'm not happy about \
that proposal is to have different enum for each of the archive types - that clearly \
breaks the transparency.

Therefore, I'd rather stick to Gary's proposal, i.e. independent interface that could \
be or not implemented by the specific ArchiveEntry. Still it could return -1 under \
certain circumstances (bit based stream or whatever exotic format may be used by one \
specific file within the archive).

So I'd suggest something like:

{code:java}
interface EntryOffsets {
        /** Returns the offset of data stream within the archive file, OFFSET_UNKNOWN \
when not known. */  long getDataStreamOffset();
        /** Indicates whether the data stream is continuous, i.e. not split into \
multiple files, interspersed with control blocks, etc. */  boolean \
isDataStreamContinuous(); }
{code}

About the other suggestion, whether to put it on the same level as ArchiveEntry or \
maybe into the main Archive class, I don't have so strong opinion. I feel that \
firstly it would be inconsistent, secondly the methods in Archive class usually do \
some big work which is not the case here...



was (Author: kvr):
[~bodewig] No problem,I'm sorry about the delay, I haven't found time togo through it \
and to think about it into detail...

I see your last point, it would be solvable with Java 8 default methods but we still \
maintain Java 7 compatibility, so not an option here anyway.

About the previous comment - I'm just thinking about trade-off between perfect and \
never-lying solution and something which is still quite easy to use and is \
transparent across all the potential types of archives. One thing I'm not happy about \
that proposal is to have different enum for each of the archive types - that clearly \
breaks the transparency.

Therefore, I'd rather stick to Gary's proposal, i.e. independent interface that could \
be or not implemented by the specific ArchiveEntry. Still it could return -1 under \
certain circumstances (bit based stream or whatever exotic format may be used by one \
specific file within the archive).

So I'd suggest something like:

{code:java}
interface EntryOffsets {
        /** Returns the offset of data stream within the archive file, OFFSET_UNKNOWN \
when not known. */  long getDataStreamOffset();
        /** Indicates whether the data stream is continuous, i.e. not split into \
multiple files, interspersed with control blocks, etc. */  boolean \
isDataStreamContinuous(); }
{code}

About the other suggestion, whether to put it on the same level as ArchiveEntry or \
maybe into the main Archive class, I don't have so strong opinion. I feel that \
firstly it would be inconsistent, secondly the methods in Archive class usually do \
some big work which is not the case here...


> Expose zip stream offset and size via API
> -----------------------------------------
> 
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
> Affects Versions: 1.13
> Reporter: Zbynek Vyskovsky
> Labels: features, github-import, patch
> Fix For: 1.14
> 
> 
> In certain cases it may be useful to get information about where in the archive the \
> stream starts and ends. Typically when zip is used as resource container and the \
> resources are then mapped directly into memory, but not only. The size and \
> compressed size are already available but not the stream offset. This can be \
> applied to other archive types as well, therefore it would make sense to put this \
> into basic interface - ArchiveEntry. But not necessarily all of them have to \
> support it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[prev in list] [next in list] [prev in thread] [next in thread]