On Thu, May 1, 2008 at 5:05 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> 1) How do we create a sliced? input.slice(count). Same as skip(count) but by reusing the relevant buffers / arrays and returning them as a new stream. Even overlapping buffers at the beginning/end are no problem, assumed that every buffer is wrapped by a wrapper instance that holds the valid range. Buffer: AAAAAABB Wrapper at the end of Stream A: (Buffer,0,6) Wrapper at the beginning of Stream B: (Buffer,6,8) Also new buffers can be appended to both streams without influencing each other. > 2) How do we slice an InputStream if we only know the size of the slice > after we read something and the slice should begin from the first byte > of the stream? > One possible solution to Q2 is to support mark() and reset() operation > in InputStream, but it means we can't release the related resources even > if the stream has reached to its end, because reset() can be called at > any time. We might need something better? The only thing is, that no automatic dispose() can happen to buffers that are relevant to the marked position if set, which is completely ok because this data is of importance when using it. If it is not set explicitly, the stream should just free buffers automatically. Maybe there should be an additional method to discard the marked position without resetting: IoInputStream.mark(readlimit); // readlimit is very useful for us (see InputStream API) IoInputStream.reset(); // Reset to the marked position and clear it; throw IoException if mark has not been set + IoInputStream.discard(); // Discard/free everything before the current position (marked position = null, buffer references not used any longer) When supporting mark, even basic random access is possible, by subsequent calls to reset() and mark(). Some sort of IoInputStream.moveTo(int) relative to the marked position could make this even easier and also make sure that nobody needs to switch back to the lower level ByteBuffers / byte arrays for random access. However, there are only very few cases where random access is really required. regards Daniel
