mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <paliwalash...@gmail.com>
Subject Re: Google Protocol Buffer codec...
Date Sun, 11 Jan 2009 10:50:14 GMT
On Sun, Jan 11, 2009 at 3:25 PM, James Mansion
<james@mansionfamily.plus.com> wrote:
> Ashish wrote:
>>
>> with prefixed string decoder. We have a length and then actual
>> messages. It will be worthwhile to explore if we can align the google
>> codec with prefixed string codec.
>>
>
> Almost all message-oriented protocols seem to have:
> - a fixed length header containing a length, possibly implied
> - the payload

Agree

> I suspect that you can abstract most with a general binary framework that:
> - defined the fixed length part
> - registers a callback that can process the fixed length header and return
> the payload length
> - registers a callback that receives both the fixed length header and the
> payload
>
> The key is that the length need not be at the start of the header, and may
> be computed.
>
> The dificulty is deciding how to handle long payloads.  It may be that for
> long data
> you should stream to a file and then pass header plus stream - but doing so
> implies a
> piecewise payload handler and that should probably be exposed too for cases
> where
> the application wishes to process as it goes.
>
My comment was more from perspective that, such frameworks are good if
we are starting from scratch :-)
For most of the well established protocols like FTP, HTTP, SNMP, LDAP
etc, they don't do a value add.
Essentially, if we have some framework to reduce development work with
these AL protocols, would be great.
Lets see, if someone does something on these lines in PhD thesis :-)

Mime
View raw message