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.
Just because JAVA base object are signed ;) And, yeah, BB is a losy API...
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.
Ahhh... Good old time, where I was able to handle registers in my
prefered assembly code :) May be we are getting too old, Julien ;)
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.
It still is, but you have to wake up early !
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.
The secret of a good decoder lies much more on knowledge about statefull
state machines than the byte storage. As soon as you can grab a single
byte, you are all done. (I mean, it's now up to you to deal with the
decoding of your incoming flow...)
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 ?
I agree with Julien here, and have expressed the concern in another mail.
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 ?
One concern I have about encoding is that usually, I have to compute the
size of the encoded BB before being able to feed it with some encoded
data, just because the BB has a fixed size, and also because my protocol
mandate me to store the PDU size as the second piece of information of
my PDU ( Type, Length, value ...)
Otherwise, it's not really a problem for many protocol, as they can feed
fixed BB and send them to the underlying writer without bothering about
the gathering (which can be handled with a GatheringByteChannel )
Julien
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
