Parse messages and events based on byte arrays instead of strings #10
Conversation
|
This is a valid request, and the implementation needs to be looked at carefully to avoid thrashing the Garbage Collector in high-traffic applications. If my memory serves me correctly I have looked into it in the past and hit an obstacle with cleanup. |
|
And we are in Modern DotNet where we now have The original NEventSocket was intended to run on Mono as well as DotNet, we can make some big improvements now that dotnet is properly cross-platform. |
…of a UTF-8 string. This byte array is then used for further parsing in the derived EventMessage class to save converting back again to a byte array from a UTF-8 string. Tests have been extended to include a DetectedSpeech event. There are two variants of this event which are used in the tests, one containing a response with English text in the body and another containing German text and umlaut characters. Add Logger initializer to MessageParsingTests class to allow its test cases to be run independently. Add new test case to MessageParsingTests to test for the successful extraction of body payload from the EventMessage.
ajgolledge
force-pushed
the
parse-multibyte-encoded-byte-arrays
branch
from
74cd2ff to
804a0b9
Compare
|
Would somebody be able to take another look at this? We have been using it in production ourselves for a few years now. |
|
I'll take a look. I see that #26 is related. Although it is an internal behavioural change, I think we should release with a Major Version bump. I hope this will encourage users to test thoroughly before deploying to production. |
4 participants
Parse responses encoded in multibyte character sets (e.g. UTF-8) correctly by applying the content length given in the response to the length of the raw byte array and not the encoded string. The length of the string and the length of the byte array are not necessarily equivalent.