Hi, Look like I'm late, you should try to slow down on the reply button guys ! It's hard to follow :)
On Mon, 28 Apr 2008 22:21:57 +0900 (KST) "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote: > I thought about the current MINA API these days while I am idle, and > got some idea of improvements: > > 1) Split IoBuffer into two parts - array and buffer > > IoBuffer is basically an improvement to ByteBuffer. Improvement here > means it inherited some bad asset from ByteBuffer - all the stateful > properties such as position, limit and mark. I think they should be > provided as a separate class, and there should be classes dedicated > for storing bytes only (something like ByteArray?) > > BTW, why is mixing them a bad idea? It's because it makes the > implementation too complicated. For example, it is almost impossible > to implement a composite buffer to support close-to-zero-copy I/O. > What about all the weird rules related with auto-expansion and buffer > derivation? It's increasing the learning curve. I never liked BB, I find it painful to use, and the plain Sun API don't even give method for dealing with unsigned types. The byte array is probably sucking even more, because you can't cast it like in C to the type you want and fetch the data. the ones who ever wrote a binary decoder in C understand what I mean : gather enough bytes in a buffer, cast the buffer pointer to the good struct/type and extract the data, increment the pointer to the next step. Now compare that with freaking BB decoding, sweep, mark,slice, get, apply & 0xFF for handling sign.. and if you want to extract a bunch of structured data in 1 pass, it's impossible. I think the problem is the way you implement decoder in Java using the ByteBuffer abstraction, the way we extract structured data . I have no clear solution, but if we work out a good practise for writing binary decoders (text are excluded, it's too easy ;) ), we will have clearer view of the base buffer we need to have for producing great/fast/simple decoders. > > 2) Get rid of IoHandler and let IoFilter replace it. > > IoHandler is just a special IoFilter at the end of the filter chain. > I don't see any reason to keep it special considering that we are > often building multi-layered protocols. Agree. > > 3) Split IoFilter into multiple interfaces. > > If IoHandler is removed, IoFilter should be renamed to represent > itself better. Moreover, IoFilter should be split into more than one > interface (e.g. UpstreamHandler for receiving events and > DownstreamHandler for sending events from/to an IoProcessor) so they > can choose what to override more conveniently. Do we really need it ? Isn't going to clutter the API ? > > 4) UDP as the first citizen transport. > > MINA currently handles UDP like it's a TCP connection. Consequently, > we had to provide some additional stuff like IoSessionRecycler and > IoAcceptor.newSession(). IMHO, session state management should be > completely optional when a user is using the UDP transport. Possible > solution is to provide a different handler and session interface from > TCP. > > How do we execute all these changes? Well.. I think it's pretty easy > to do purely from technical point of view. All the changes will make > users experience bigger backward incompatibility, but these issues > should be fixed somehow to make MINA a better netapp framework IMHO. > The multihoming and connection less nature of some transport (UDP multicast, RS485, CAN, ethernet) aren't really mixing well with MINA, but perhaps it's out-of-scope for MINA ? I think no, because the whole decoding process is nearly the same. > Any feed back is welcome. If we focus on providing a great codec framework, we will know what we need as underlying engine. Actually we have to many helpers and way to make a decoder with MINA and it's not helping much to decide if we need to use expendable buffers or compositing byte arrays. I know some wants the two, but do we really need it ? Julien
signature.asc
Description: PGP signature
