LengthHeaderMessageHandler but little endian

[november06]

Excuse me, I am trying to call a python json rpc server and I need a LengthHeaderMessageHandler with Little Endian. Is there any easy way to achive it?

I end up copying quite some code from LengthHeaderMessageHandler/PipeMessageHandler, since I didn't find an easy way to customize. Some function in PipeMessageHandler was "private protected". So I cannot reuse directly.

(Let me know if there is any document that I should have read)

[AArnott]

Are you sure endianness is the only incompatibility between the python server and this .NET implementation?

[november06]

TL;DR: In my case it was not. I also changed the request Id to a string, instead of an integer. My point was, why not support both big and little endians?

Details:
It was a bit complicated than I described.
We had a partner team who used a python client to invoke a Json RPC server, written in C++. (Look at the FPocoWorker::HandleRequest and FPocoWorker::SendResponse methods in Poco-SDK). Since the python client worked, I assume the server works according to the json-RPC spec (where I didn't find much details on the messages/payloads format), to some extent.

The following are all my humble opinions:
At the end of day, I just wanted to write a very simple business logic and I don't want to spend my whole day on the implementation details of an underline library. I have gotten my program working and it will not be a strong business requirement for you, I guess.
I post mostly just because I feel it's less elegant to support only big endian. And making the library compatible with a python implementation is a different story, I guess.

[AArnott]

Fine feedback. Thank you.
The JSON-RPC spec is completely silent on the question of headers, message delimiters, or even character encoding. This makes interoperability a bit of a challenge. We introduced LengthHeaderMessageHandler to provide one way to send multiple messages between processes. We had no need for multiple endian support, nor any reason to believe there was another implementation out there that would be compatible if only the other endian mode were supported.

We have support for string-based request IDs too. It's orthogonal to the message handler.

I have no objection to adding a boolean property to the existing message handler to add the endian switch. I would just need your assertion that it'll allow you to match interoperability with another.

[november06]

Thank you very much for the reply.

It will be sufficient for my case, given that I can use string-based request IDs.

On the other hand, I have gotten the code working on my side now. So it's OK that you don't change anything in the end. I can totally understand.