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 wrote:
> You're right, in same time
You're right, in same time mina-http doesn't have HttpEntity equivalent.
We could start without them and add them in second step
2013/1/3 Julien Vermillard :
> 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
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,
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 po
Taking a look now. Looks like the code is not really commented :(
On Wed, Jan 2, 2013 at 12:08 PM, Ashish 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, 2013 at 11:53 PM
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 wrote:
> Definitively should take a look.
> The only tricky issue is streaming large content, because MINA
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" a écrit :
> Hi,
>
> Happy new year 2013.
>
> I'm strongly interested in HT
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 easy
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 wrot
we should think of a codec as an independant module : it should be
available for any java code that just needs suh a codec for its own purpose.
such a need has already been expressed for http.
imo, the current impl is over-ingeniered.
Btw, it seems that we are up and running at 9am on jan. first
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 un
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 Code
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
> call
ther, which may be useful
for protocols which specify 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. O
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, parse
15 matches
Mail list logo
