[MINA 3.0] Standard Codec was Re: [MINA 3.0] Which filters should we keep ?

[Emmanuel Lecharny <el...@gmail.com>]

Niklas Gustavsson a écrit :
> On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny <el...@gmail.com> wrote:
>   
>> I was also thinking we should add some more filters like :
>> - a XML filter
>> - a JSON filter
>> - a HTTP Filter
>>     
>
> Don't think these should belong in MINA Core (but that probably not
> what you are proposing either). But, they would be useful as some kind
> of subproject/part of subproject (like the HTTP filter being part of
> AsyncWeb). As for the XML filter, we now got a reusable, non blocking
> XML parser/renderer in Vysper (still in a branch, but soon ready for
> getting into trunk). It still needs work, especially for support full
> XML (currently lacks support for PIs, doctype declarations).
>   
We discussed a while back about the idea to offer a set of standard 
codec for many protocols. I think it's a better idea to follow Niklas' 
suggestion, and to cover this point in a different thread.

There is also a distinction we should make between protocol codecs 
(Http, Ntp, Ldap, ...) and message codecs (XML, Json, ...). The second 
kind of codec does not necessarily covers a protocol, it's just a 
support, a bit like the TextLineDecoder is not a protocol. I don't know 
if I'm clear enough, so I hope you were able to get the message I wanted 
to transmit without the need for me to put it in a XML formet :)


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [MINA 3.0] Standard Codec was Re: [MINA 3.0] Which filters should we keep ?

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:

> Niklas Gustavsson a écrit :
>> On Fri, Jan 8, 2010 at 5:25 PM, Emmanuel LŽcharny <elecharny@gmail.com 
>> > wrote:
>>
>>> I was also thinking we should add some more filters like :
>>> - a XML filter
>>> - a JSON filter
>>> - a HTTP Filter
>>>
>>
>> Don't think these should belong in MINA Core (but that probably not
>> what you are proposing either). But, they would be useful as some  
>> kind
>> of subproject/part of subproject (like the HTTP filter being part of
>> AsyncWeb). As for the XML filter, we now got a reusable, non blocking
>> XML parser/renderer in Vysper (still in a branch, but soon ready for
>> getting into trunk). It still needs work, especially for support full
>> XML (currently lacks support for PIs, doctype declarations).
>>
> We discussed a while back about the idea to offer a set of standard  
> codec for many protocols. I think it's a better idea to follow  
> Niklas' suggestion, and to cover this point in a different thread.
>
> There is also a distinction we should make between protocol codecs  
> (Http, Ntp, Ldap, ...) and message codecs (XML, Json, ...). The  
> second kind of codec does not necessarily covers a protocol, it's  
> just a support, a bit like the TextLineDecoder is not a protocol. I  
> don't know if I'm clear enough, so I hope you were able to get the  
> message I wanted to transmit without the need for me to put it in a  
> XML formet :)

I never thought of HTTP as a filter but it's intriguing.  I had always  
thought that it was more application like.


Regards,
Alan