Hello,
I think it is not related to java, but a general problem of some file
formats in regards to streaming access.
If a format needs seeking/random-access there are basically three options
(with the Java classes but also other languages). The first is having a
random access file (which in this context mean you write the stream to a
temp file and work on it), the second is doing the buffering in memory
(mark/reset style). This might be a problem if you have to read from the
end of the file as you need to keep everything in between in memory. The
third option would be to allow to open the provided input stream multiple
times (eighter by providing some form on "data source" or by supporting
clone/reset on the input stream). (another option would be a random
access-like buffer, but the amount of work to do that might not be worth
it as you can easyly use a temp file).
For the 7z stream I guess the minimum which can be done is working with a
temp file. But a general idea for this (and other compressors) is a "if
you can provide multiple input streams you can use ..." API.
Greetings
Bernd
Am 30.09.2013, 18:47 Uhr, schrieb Benedikt Ritter <brit...@apache.org>:
2013/9/30 Stefan Bodewig <bode...@apache.org>
On 2013-09-29, Torsten Curdt wrote:
> Hm - it is indeed a little misleading. So I am +0 for an inclusion.
This is what I feel as well.
> Is a stream based implementation of 7z somewhat feasible - at least in
> theory?
I'm in no way as familiar with the format as Damian is but IMHO it is
feasible - but likely pretty memory hungry. Even more so for the
writing side. Similar to zip some information is stored in a central
place but in this case at the front of the archive.
Hi Stefan,
just out of curiosity: is this memory problem related to Java or to 7z in
general?
Benedikt
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
http://www.zusammenkunft.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
