Implement messages conversion #3

Messages conversion

We need to convert JSON messages that we'll accept from the network <-> some sort of inner representation.

JSON format

Expected JSON messages will consist of (message_group, message_type, contents). For example:

message_group = database message
message_type = add integer
contents = any parameters as JSON value

As JSON it would look like this: {"g":"db","t":"addi","c":{"var":"/player_id/headshots","inc":10}}.

Corresponding inner representation

Inner representation will be the enum with several options. Correspondence with JSON is as such:

message_group ~ enum type
message_type ~ enum option
contents ~ enum option contents

So for db messages enum can look something like:

enum db_message {
	SetInteger { variable: String, value: i64 },
    AddInteger { variable: String, increment: i64 },
    ...
}

Implementation details

I propose extendable system that will provide a trait, that will mark enums as inner message representation.

This trait will require two methods for JSON <-> enum conversion.

Determining to which enum to conver JSON will be based on specified message group, then enum decides which option to pick based on specified message type and parses contents into it's parameters.

Message converter

To allow having several message enums (message groups) in an extendable manner, we will need to introduce a separate message converter object that will somehow encapsulate String<->enum 1-to-1 mapping, that will link a group name to corresponding message enum.

Since it will contain part of information necessary for conversion, it will also provide a facade for actually converting messages.

Workflow would ge similar to this:

//	Not sure how best linl name and trait
//	Maybe closure would work?
manager.add_message_group("db", db_message.from_json);
manager.add_message_group("srv", servers_messages.from_json);
let message = manager.parse(json!({"g":"db","t":"addi","c":{"var":"/player_id/headshots","inc":10}}));

# Messages conversion We need to convert JSON messages that we'll accept from the network <-> some sort of inner representation. ## JSON format Expected JSON messages will consist of (message_group, message_type, contents). For example: * message_group = database message * message_type = add integer * contents = any parameters as JSON value As JSON it would look like this: `{"g":"db","t":"addi","c":{"var":"/player_id/headshots","inc":10}}`. ## Corresponding inner representation Inner representation will be the enum with several options. Correspondence with JSON is as such: * message_group ~ enum type * message_type ~ enum option * contents ~ enum option contents So for db messages enum can look something like: ```rust enum db_message { SetInteger { variable: String, value: i64 }, AddInteger { variable: String, increment: i64 }, ... } ``` ## Implementation details I propose extendable system that will provide a trait, that will mark `enum`s as inner message representation. This trait will require two methods for JSON <-> enum conversion. Determining to which `enum` to conver JSON will be based on specified message group, then `enum` decides which option to pick based on specified message type and parses contents into it's parameters. ### Message converter To allow having several message enums (message groups) in an extendable manner, we will need to introduce a separate message converter object that will somehow encapsulate String<->enum 1-to-1 mapping, that will link a group name to corresponding message enum. Since it will contain part of information necessary for conversion, it will also provide a facade for actually converting messages. Workflow would ge similar to this: ```rust // Not sure how best linl name and trait // Maybe closure would work? manager.add_message_group("db", db_message.from_json); manager.add_message_group("srv", servers_messages.from_json); let message = manager.parse(json!({"g":"db","t":"addi","c":{"var":"/player_id/headshots","inc":10}})); ```

Upon further consideration and prototyping, I don't feel that described system will help at all, - even supposing most general requirements for avarice. Therefore, this idea is scrapped.