Here a Codec interface proposal :
https://github.com/jvermillard/mina/tree/trunk/core/src/main/java/org/apache/mina/filter/codec
PS : I'm just toying around with github, don't worry I'm not making my own
fork :)
On Thu, Jan 3, 2013 at 10:20 AM, Arnaud bourree arnaud.bour...@gmail.comwrote:
I think we agree here, I wouldn't touch the NIO part, but the interface for
the message are nice. The only issue is with the HttpEntity stuff, I like
the way contents are streamed in small chunk in the mina-http codec. I'm
not sure it's feasable without forking the http-core code.
On Wed, Jan 2,
hc has nio based implementation as well
http://hc.apache.org/httpcomponents-core-ga/httpcore-nio/xref/index.html
See nio.codecs package
On Tue, Jan 1, 2013 at 11:53 PM, Julien Vermillard jvermill...@gmail.comwrote:
Definitively should take a look.
The only tricky issue is streaming large
Taking a look now. Looks like the code is not really commented :(
On Wed, Jan 2, 2013 at 12:08 PM, Ashish paliwalash...@gmail.com wrote:
hc has nio based implementation as well
http://hc.apache.org/httpcomponents-core-ga/httpcore-nio/xref/index.html
See nio.codecs package
On Tue, Jan 1,
My idea was to re-used http-core pojo classes like BasicHttpStatus,
BasicHttpResponse, ... in mina-http codec.
In other words don't re-defined Http pojo classes, just implement mina
encoder/decoder
IMO, http-core-nio looks more complex than existing mina-http and
doesn't have clear split between
. The
idea is to make life easy for the framework user. Or we can provide some
helper around our core Codec framework. Thoughts?
Yes, that's the idea, most UDP based protocols won't need accumulation, but
most of TCP based will need it.
Basically a decoder looks like : https://gist.github.com
It's sure 10 year after SEDA is quite smelly :-)
In my mind the codec code should be used by a filter for transforming the
bytes into pojos (like today) but really not dependent of MINA.
IMHO demux handler is a piece of s..t, you should use a visitor pattern.
Much more testable.
I like the loop
Hi,
I wanted to sleep, by my son wasn't agreeing :) I will probably crash later.
Yeah we could experiment with the HTTP codec, it's in pretty bad state for
now.
It would be nice to be able to share the codec code between MINA 2 and 3.
Julien
On Tue, Jan 1, 2013 at 9:45 AM, Emmanuel Lecharny
Hi,
Happy new year 2013.
I'm strongly interested in HTTP codec: I used for one project I did
for my company.
Here there are my point of view:
- share codec between MINA 2 and 3: I initially take MINA 3 as base to
implement on MINA 2 and keep classes and package structure. BTW share
should be
Definitively should take a look.
The only tricky issue is streaming large content, because MINA have an
event based paradigm where H.C. have probably a stream based approach.
Julien
Le 1 janv. 2013 16:33, Arnaud bourree arnaud.bour...@gmail.com a écrit :
Hi,
Happy new year 2013.
I'm
length or fixed headers. User provides how to
find length, Framework shall accumulate bytes and once done, can pass on
complete PDU for decoding. This might be an overhead in some cases. The
idea is to make life easy for the framework user. Or we can provide some
helper around our core Codec
Le 12/31/12 7:55 AM, Julien Vermillard a écrit :
Hi,
Since few year, I stopped to use the MINA ProtocolCodecFilter and
associated stuff (CumulativeCodec..). for implementing my own codec
independent of MINA.
it's just a service consuming ByteBuffer and pushing decoded POJO in a
callback.
Hi,
Since few year, I stopped to use the MINA ProtocolCodecFilter and
associated stuff (CumulativeCodec..). for implementing my own codec
independent of MINA.
it's just a service consuming ByteBuffer and pushing decoded POJO in a
callback. The point is to be independent of MINA for example,
13 matches
Mail list logo
