commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zbynek Vyskovsky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
Date Thu, 27 Apr 2017 05:53:04 GMT

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

Zbynek Vyskovsky commented on COMPRESS-390:
-------------------------------------------

I checked the 7z implementation and it seems that the data streams are quite straightforward.
The only thing that can happen is that it would spread across several files when the archive
is split to several volumes. I already started looking into implementation and maybe will
add it soon.

But as I mentioned, the typical use case for this requirement is resource container so we
don't care about the situations above. So the resources like libraries, images and stuff like
that, written using stored method and which could be mapped into memory instead of being read
as a stream. That's something at least both zip and 7z support. Probably most of others as
well but they're not so suitable for such usage as they usually don't have entries directory.

I agree about the difference between local directory and central directory for zip. But referring
to the use case above, the header offset is not really too interesting, it's all about data
offset and the entry size. So I don't mind changing it, although it may be impossible for
ZipArchiveInputStream for example...

About the last part - making it Zip specific. I started with that but then thought it's always
better to have unified API unless there is something really specific for that implementation.
This is something I'm already facing now - currently when working with Zip and 7z for example,
I need two completely different pieces of code around them as both of them have significantly
different API (at least they're completely different classes with no shared interface). While
I would expect single interface for all archive types, similar to what is defined for ArchiveInputStream.
Therefore, I tried to avoid the same issue for this change. (and started thinking about that
common interface)


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

Mime
View raw message