이희승 (Trustin Lee) wrote:
On Wed, 21 May 2008 10:08:27 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
We may need to deal with bits. ASN.1 PER decoder needs it.
Yes. Probably in the decoder? I don't think we should have bit
getters/putters in our interface. Then we should add all the bells
and whistles together. :)
Agreed.
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.
Just a question : do we need all those offerXXX() methods ? The type
will be enough to select the correct method. And I also suggest that
the default implementation should be for bytes, and that we have
inherited classes for int, float, etc... which would make the
implementation much easier (less methods).
We need them like ByteBuffer provides them. It's also important from
performance perspective because reading 8 bytes in a row with one call
often outperforms reading 8 bytes with 8 calls. We are going to
provide access methods for all primitive types (except for boolean)
eventually so I don't think it will lead to less methods in total.
Yeah, you may be right. It makes sense to read a byte, then a long, then
two integers...
Another things would also be to get a byte[] getBytes( in length )
method returning as much bytes as possible, up to a length. If the
number of available bytes is below the length, the returned byte
array will only contains the available bytes, and it will be up to
the decoder to deal with it. The idea is to avoid calling the
element() method for every single byte we want.
It sounds similar to ByteBufferQueue.pollSlice(int length), but
pollSlice() returns null when there's not enough data.
Would be better to returns what has already been read. Sometime, you are
just proxying the data, and you want to send it to the next consumer as
soon as you get some. Otherwise, the queue will buffer potentially
gigantic data in memory. (This is something we experimented with
JpegPhoto data in Ldap, this is the reason I mention it).
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
