Add protobuf alternative to JSON

[WheteThunger]

Problem statement

Today, server side mods (Oxide plugins, Harmony mods, etc.) can send custom UIs to clients by passing a JSON string through an RPC call. This results in multiple problems.

• Requires 3rd party libraries or DIY to build and serialize UIs, since the server side assemblies don't have any bundled utilities for this, notably putting Harmony mods at a disadvantage, and resulting in duplicated community effort as multiple frameworks and server networks reimplement basically the same library
• Common patterns for building UIs (e.g., create, then serialize with Newtonsoft) strains the CPU and allocates a significant amount of garbage, resulting in various developers attempting to build solutions to this problem which pool objects, cache string representations of numbers, and build JSON using character arrays (most notably dassjosh/Rust.UIFramework), which should not be necessary and is not accessible to developers who want to distribute mods without dependencies (or thousands of lines of bundled code)

Proposed solution

• [Client & Server] Implement protobuf classes for CUI elements and CUI components (can be mostly auto generated), and include those classes in server side assemblies for mod developers
• [Client] Implement new RPC call (e.g., AddUIProto) so the server can send a UI as a protobuf payload
• [Client] Refactor this code base to build UIs from protobuf classes rather than from JSON objects
• [Client] For backwards compatibility, implement deserialization from JSON to the protobuf classes

Benefits:

• Smaller payloads
• Reduced CPU usage when building UI payloads
• No garbage allocations when building UI payloads
• No 3rd party library needed for vast majority of existing use cases, improving accessibility to all modding frameworks
• Allows 3rd party library developers to focus on higher level concerns such as building abstract widgets

[Kulltero]

definitely agree, ProtoBufs could massively shrink packet size when building large UIs. a question i'd have is, how much would deserializing to ProtoBuf cost if it just gets used to build the panels & components? its a better option than maintaining 2 deserialization code paths but wouldnt it add some cost to using the JSON method of adding UIs?

even when the change gets made, alot of mods using the CUI system would probably still be on the JSON system as most of them are oxide mods using the built in functionality. i'm unsure if the oxide wrapper could be transfered over to the ProtoBuf version without breaking changes for existing plugins

i do see the benefits though, hopefully it would offset some of the bulk some of My PRs would add to the JSON payload :P

[TurEduard]

I also wanted to write such a post. let's share the links and bring more attention to it. I would like to add that CUI also lacks functionality. For example, specify a hover color for a button (focus). The ability to cache CUI on the client side, for example during a connection, and trigger rendering at the required moment using a key. This will significantly reduce the load on the network and prevent massive DDoS when players intentionally cause rendering frequently. Fortunately, the latest update added support for scrolling.