Hello Trustin,
> I chose java.util.Queue because we can reuse existing interface > (java.util.Queue) and people knows what Queue is as they know what > Input/OutputStream is. Naming it a queue with removeXy getters instead of some non-standard stream sounds good so far, so the non blocking and automatic dispose ideas become clear directly and the concept is basically the same like the proposed streams. However, I am still missing some setOrder(ByteOrder order). And what about slicing contents from the buffer? Does it *copy* the contents to a new bytebuffer or is a composite buffer used in the background to achive zero-copying when slicing over multiple (including partial) buffers? Or is it not meant to deal with a ByteBufferQueue this way and reuse a duplicated instance instead for further reading? > ByteBufferQueue is what a codec or low-level filter will interact with. It > has all the sequential getters and putters including random access getters > based on byte offset. It supports minimal set of types, but more access > methods will be provided as static methods of a utility class. Our long > term goal is to provide a codec generater so that a user doesn't need to > spend a lot of time to implement any kind of codec, so keeping it minimal > makes sense. I don't really understand why it is neccessary to create an utility class for reading e.g. Strings instead of implementing it directly into the ByteBufferQueue. Or is it planned to reuse the utility class on ByteBuffers *and* ByteBufferQueues however the getters and setters are named differently? Or is there a plan to provide other ByteBufferQueue implementations other than using...ByteBuffers? ;). If not, then I don't get it. > All methods have been named after the methods in Queue, so it might sound a > little bit long, but it shouldn't be a problem in the long term with the > codec generator. For me personally this is absolutely ok, but didn't you mention yourself, that this will make it more complicated changing from IoBuffer upwards for users? > It satisfies most needs except that it doesn't have additional random > access operations such as mark/reset, movePosition and random putters. I > dropped them because we can still read the buffer randomly using > elementAsXXX(int offset) methods. Considering random access operations are > not used often, it should be OK. Especially with the codec generator, the > number of random access operations should be minimal. I aggree. The random access getters can do the job somehow. However, let's say an immaginary protocol uses NUL terminated strings and somewhere between them offsets to those strings as e.g. short values and there is a need to randomly jump to a specific NUL terminated string inside the buffer to read it. As far as I understood, there will be an utility class for reading strings. So then, will every utility method have an optional offset parameter? Will every random utility method return the real number of bytes read (e.g. when reading UTF-8 Strings with multibyte characters, the real length cannot be determined perfectly afterwards). Without, this kind of protocol will be hard to decode because the utility class could not be used at all. > PS: Yes, I think it's time to finish this stuff quickly and move on to the > codec generator. Yes, I am already curious to use the generator :). regards Daniel
