Hi,
이희승 (Trustin Lee) wrote:
Hi,
I've just checked in the following three classes:
* IoQueue - a Queue (java.util) which supports event listeners
* IoQueueListener - an event listener which is notified whenever a new
element is going to be added, added or removed
* ByteBufferQueue - an IoQueue which provides special access methods
for primitive types
The source code is available here:
http://svn.apache.org/viewvc/mina/branches/buffer/core/src/main/java/org/apache/mina/queue/
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.
IoQueueListener is similar to IoEventQueueHandler
(org.apache.mina.filter.executor). It can be used to throttle IoQueue
dynamically, just like IoEventQueueThrottle does. The difference is
that it works with any type of objects including ByteBuffer rather
than just IoEvent. This allows a user to reuse this framework even
after codec finished decoding (i.e. SEDA friendly).
We may need to deal with bits. ASN.1 PER decoder needs it.
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.
+1
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).
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.
it should be null :)
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.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
