Julien Vermillard wrote: > 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.
You still have to swap the bytes for each fields to assure your application is built and run in different architectures. Java just don't provide a way to copy fields like that unfortunately, no matter type (ByteBuffer or ByteArray) we use. > 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 . Agreed. For Java, what we can ask is just 'which abstraction is better?' My point is to separate state information from data. Like we did in C with malloc(). Using ByteBuffer is like changing the value of the return value of malloc() not storing its initial value in that position and limit can be changed whenever user wants. > 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 ? Right. That's why I changed my opinion - let's just replace IoHandler with IoFilter. >> 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. I can't think of a nice solution yet. The current UDP API just needs a little bit more of learning. >> 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 too 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 ? The problem is not in expandability but in the cost of copying on expansion. Composite byte array is one of the ways to resolve such an issue. Less copy is better IMO. Thanks, -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
