On 17/04/2012 22:23, Xueming Shen wrote:
Given the sequential nature of the zip stream, it's a kinda of hard to
implement the
position(long) method for a "pure" zip byte channel. You don't want to
jump either
backward or forward N bytes when writing and appending (we don't have
a "position
mapping" between the compressed and uncompressed data, so you simply
can't
"position" to a desired N pos when compressing), and for the same
reason you don't
want to jump back either when reading, the only "meaningful/doable"
position(N)
operation is when N> position() for reading, which is basically a
"skip N - position()
byte" operation.
In order to implement the position(N), for writing, you have to write
all the data
without compression into a "buffer", you then can "position(N)" on it.
And only do the
real compression upon closing. For reading, you have to de-compress
the whole zip
entry into a buffer first, then build a channel on top of this buffer
for the reading/
positioning. This is how newFileChannel is implemented now.
-Sherman
Right, a SeekableByteChannel allows for random access but you don't know
in advance how the channel will actually be used, it may only be used
for sequential access. Given that the zip provider supports FileChannel
then maybe it could be implemented so that it switches (behind the
scenes) to a FileChannel when position is invoked to seek to a
position<current. For the read (or read+write) case then
position>current can just skip as you suggest, the write-only case would
have to switch to a FileChannel. It will likely to be tricky of course.
BTW: This the comment was just a passing comment when looking at Paul's
patch, it's of course a several issue/project that should preclude
Paul's fix from going in.
-Alan
