Here are some thoughts : As you mentionned, buffer design is tightly linked to the codec filter and stream API mina will offer to users. The current ProtocolEncoder/Decoder interfaces :
void encode(IoSession session, Object message, ProtocolEncoderOutput out) void decode(IoSession session, IoBuffer in, ProtocolDecoderOutput out) would give, with Stream<K>, something like : void encode(IoSession session, Stream<I> in, Stream<O> out) void decode(IoSession session, Stream<I> in, Stream<O> out) Note that this looks pretty clear at the first sight for the user. The K parameter in Stream<K> would in practice be : * a ByteBuffer or a ByteBuffer array for the in stream of decode() and out stream of encode() for the outermost codec filter * a Pojo for all the other streams Now, if we consider these Stream objects as blocking queues, then the Stream interface bring us a convenient first step of the SEDA design which is in the Mina 3.0 wish list (http://mina.apache.org/mina-30-design.html). The other part of the SEDA stage design would be a thread pool which could be optionally put in front of filters to make their execution asynchronous. Following this idea Stream interface would, in its simplest form, look like : public interface Stream<K> { void write(K item); K read(); } Maybe in this context read() / write() would confuse the user about what is actually done, so it may make sense to expose methods such as getNext() / put(). The underlying implementation could be a blocking queue, a priority queue (if we want to enable some easy to implement QoS filters), a synchronous invokation of the next filter in chain, ... In this scenorio, expecting ByteBuffer arrays and not just ByteBuffers as parameter of Stream seems to be a prerequisite to allow message reordering (once again for QoS, or just due to some protocol logic), as complex messages may be written in several ByteBuffers. Here, Stream would actually become a extended remplacement for IoBuffer. Comments about all this ? Does it make sense ? Michael On Mon, May 10, 2010 at 2:11 PM, Ashish <[email protected]> wrote: > Time to be back to 3.0 :) > > We had couple of discussions around Filter Chain, Selectors etc. > Meanwhile, I just took a step back and was wondring how would we pass > on data around aka buffer design. > > From our 3.0 design page we have these two bullets > > - We should not wrap ByteBuffer into our own IoBuffer class. We should > have a list of ByteBuffers instead, containing all the ByteBuffers.. > - The chain API should be modified to expose Streams of generic types > (Stream<K>) instead of IoBuffer, allowing us to add more than one > codec filter in the chain (each Filter being aware of the kind of > Object it can manipulate) > > I think it would be a good idea to have some brain storming around > this and have something concrete for this. Since it will be one of the > core constructs, we would need it at most of the places. > > Thoughts? > > thanks > ashish >
