You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently compile-frame supports pre-encoder and post-decoder methods to manipulate the data-structure before/after use with a codec.
I'm currently using a third scenario - a pre-decoder method which manipulates the ByteBuffer being passed to a codec before decoding.
This is useful to me, because the RFC-5322 spec supports un-folding of headers before parsing, and I do that pre-decode.
A different solution would be to have a look-ahead style String codec which interpreted some byte sequences "\r\n\ " and "'\r\n\t" as simple space characters, but that seems more complicated, particularly as those byte sequences are super-sets of the "\r\n" delimiter.
Hi Zach,
Currently compile-frame supports pre-encoder and post-decoder methods to manipulate the data-structure before/after use with a codec.
I'm currently using a third scenario - a pre-decoder method which manipulates the ByteBuffer being passed to a codec before decoding.
This is useful to me, because the RFC-5322 spec supports un-folding of headers before parsing, and I do that pre-decode.
A different solution would be to have a look-ahead style String codec which interpreted some byte sequences "\r\n\ " and "'\r\n\t" as simple space characters, but that seems more complicated, particularly as those byte sequences are super-sets of the "\r\n" delimiter.
More information here:
http://derek.troywest.com/articles/by-example-gloss/#gloss-extension
I could just parse my ByteBuffers prior to using the codec, but it seemed useful to append this transform method to the codec itself.
Again, I'm happy to supply a pull-request if you think it suitable.
Ta,
Derek
The text was updated successfully, but these errors were encountered: