Re: Piggypack Encoding/Decoding on RandomAccessFile
On 11/3/2011 10:06 PM, Jan Burse wrote:
Jan Burse schrieb:
So they are somehow interlocked.
From the file channel java doc we have:
"Where the file channel is obtained from an existing stream or
random access file then the state of the file channel is
intimately connected to that of the object whose getChannel
method returned the channel. Changing the channel's position,
whether explicitly or by reading or writing bytes, will change
the file position of the originating object, and vice versa.
Changing the file's length via the file channel will change the
length seen via the originating object, and vice versa.
Changing the file's content by writing bytes will change the
content seen by the originating object, and vice versa."
In case that the file input/output stream is interchangeable
with the file channel, then they are interwoven.
But how do you maintain the state of the encoder/decoder,
if that state is a function of anything more than just the
file position itself? If the decoder must process all the
bytes prior to B[n] to get itself into the proper state for
decoding B[n], random access just makes no sense.
Well, I guess you *could* make a preliminary sequential
pass over the data, and build a Map<ByteOffset,DecoderState> for
selected positions. You could even build the map incrementally,
adding new entries whenever the random access pattern takes you
into formerly uncharted territory. Either way, though, the first
exploration of each byte position has to be sequential to allow
the decoder to accumulate its state. And if you ever *write* to
the middle of the file (which changes the encoding of all the
bytes that follow), ... I think the cases in which such a scheme
might be practical would be "unusual," if not downright "contrived."
--
Eric Sosman
esosman@ieee-dot-org.invalid