Split JsonMessageCodec out from JsonMethodCodec #150
Conversation
Separates the basic JSON<->byte stream logic out into JsonMessageCodec, which is an eventual part of the final channel interface. Eventually this class will inherit from a generic MessageCodec interface, but in order to make this functionality available for library use while the type handling of the public interface is worked out, the new class is internal for now.
|
I forgot Francisco is not available to review at the moment; awdavies, would you mind taking a look at these patches? (See the last comment pull 144 for context on why they are being done as isolated steps.) |
| std::unique_ptr<std::vector<uint8_t>> EncodeMessage( | ||
| const Json::Value &message) const; | ||
|
|
||
| // Returns the MethodCall encoded in |message|, or nullptr if it cannot be |
There was a problem hiding this comment.
Maybe I'm misunderstanding this comment, but it looks like MethodCodec is taking responsibility for this (getting the MethodCall encoded in a |message|), and that MessageCodec is just here to verify and decode that some kind of valid JSON message was received, not necessarily anything adhering to a specific protocol.
To me this implies that there's some more specific checking/verification happening within this method before returning the final Json::Value.
If it is the case that this is supposed to be more general, I might also ask that beyond updating this comment, to update the class header as well. It seems this is just a generally JSON message decoder rather than one that verifies any codec.
There was a problem hiding this comment.
Sorry, this was a copypasta. It should have been s/MethodCall/message/. I'll fix and re-upload tomorrow.
For more context, the Flutter APIs that I'm moving toward following have:
- MessageChannel: A named channel for communicating between Flutter and platform code. A MessageChannel has a specific codec associated with it at creation (JSON, Standard, etc.) but beyond that doesn't have any expectations about the contents, so clients can define whatever structure they want.
- MethodChannel: A layer on top of MessageChannel which adds a few expectations about structure: the incoming message should have a method name and optional arguments, and there should be a response that communicates success/error/not-implemented using a defined structure.
The Codec family of classes has the same split, with the MethodCodec family knowing about encoding/decoding that added layer of structure.
Our existing Plugin API doesn't have this distinction, because everything we built it to interface with so far has used MethodChannel on the Flutter side. But we do want to support it in general as part of the API alignment I'm working on, and in particular it's relevant now because the raw key event handling code in Flutter uses MessageChannel rather than MethodChannel.
So this is a small step toward adding that separation in the desktop APIs as well.
If it is the case that this is supposed to be more general, I might also ask that beyond updating this comment, to update the class header as well. It seems this is just a generally JSON message decoder rather than one that verifies any codec.
In the Flutter API terminology, a (Message)Codec is just an encoder/decoder. It's not until you get to the MethodCodec layer that there's an assumed structure beyond how different data types are represented. I could make the class comment slightly more generic by removing the reference to channels, but the reason the Codec classes exist as an API is for use by channels; if someone wanted to do JSON encoding/decoding for reasons other than channel messages they should just use an existing JSON API (e.g., jsoncpp) directly.
Separates the basic JSON<->byte stream logic out into JsonMessageCodec,
which is an eventual part of the final channel interface.
Eventually this class will inherit from a generic MessageCodec
interface, but in order to make this functionality available for library
use while the type handling of the public interface is worked out, the
new class is internal for now.