Let me snip and comment - I agree with you entirely. :)
On Wed, 21 May 2008 08:34:24 +0900, Daniel Wirtz <[EMAIL PROTECTED]>
wrote:
What about slicing ByteBufferQueues to another ByteBufferQueue by default
while reusing (e.g. duplicate() while using the same underlying byte
array)
the affected underlying buffers...with the ability to transform the
contents
to a single bytebuffer for backward compatibility (queue.toByteBuffer())?
When doing this, the default behaviour will be zero-copy and ByteBuffers
will still be used. I think mixing ByteBufferQueues with ByteBuffers by
the
default implementation is not a perfect behaviour. If I slice a Queue, I
expect a Queue to be returned in the first place.
What an idea! I like it. Then we don't need to introduce a new buffer
type. :)
We still need to make the static methods public then.
My idea is to provide something similar to ANTLR. The difference is it
works in a binary level (or course including text level) and it
generates
non-blocking MINA ProtocolDecoder. Once properly done, we could
replace all
existing codec with this and the maintenance cost will drop down
dramatically. Instead we will have to maintain the decoder generator
big
time, but it's more entertaining. :)
I thought about such a concept a little bit today and I am not yet
convinced
that this will be practical. I think the generator would be very complex
because very different rule sets and transformations need to be
implemented
depending on the task. In some cases even callbacks will be inevitable.
Also
error hooks that generate some output and close the connection (or keep
it,
or jump to some other state etc.) will be challenging. Ok, this may be
some
fun for a while but it may also be just one step too much for a
networking
framework, that already is so easy to work with. In most cases I think
it will be much easier to implement a protocol using switch() - also the
proposed queues will make this a pleasure ;). Ok, maybe a generator can
create more efficient code in some cases but it may not in every case
(most
protocols are different/exotic by nature), and as I said I'm not
convinced
that using the generator will be easier. However, if you decide to stick
with it, I'll of course try it out someday ;).
Who knows? We didn't even implement a line yet. :)
It's true that MINA should provide a convenient way to build a codec even
if we are going to provide a good tooling in the long term. We will see
what flesh we will add to the current prototype while we port examples and
filters.
Thanks!
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
