Hi Daniel, Sorry for the late response. Just got connected to the Internet after landing down to SFO.
IIUC, you are suggesting an InputStream which allows movable position to address the question #2. Doesn't it effectively make InputStream random-accessible? If it's non-blocking and random-accessible, what would be the benefit of using InputStream? I am asking these questions because it sounds like the current IoBuffer without limit() and some complications. The unique advantages of using InputStream instead of our custom interface I can think of right now are: * Users already know InputStream very well. * We can reuse all the existing stream wrappers around the world. Ans possible disadvantages are: * We violate the default blocking behavior of InputStream, so existing wrappers might not work as expected unless the whole message is read, and reading the whole message might lead to OOM so the wrappers available might not be that helpful. * The change is pretty big comparing to what we gain? (we don't care much about how big the change is though ;) Daniel Wirtz wrote: > On Thu, May 1, 2008 at 5:05 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > 1) How do we create a sliceqd? > > > 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 -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
