TheFramework

Outline

• Multi-user realtime 3d graphics editor.
• Microservice inspired architecture. But use IPC/shared memory when possible.
• Need a local daemon as a gateway/introducer for the services.

• Hash all the things.

RPC

Big Picture

• Request specific object types 'get_vertices(vid)' or just 'get(id)'?
• Non-specific seems better. Can just use a global async que for all returned things.

Message Format

• Maybe just use Rust structs? Can redefine them separately later...
• Could use codegen... Can go from Rust structs to external format or visa-versa.
• Could keep them in Rust native and provide a C library interface to interact with them.

Capnproto?

• A bit of a pain to integrate into Rust.
• Plays well with other languages.
• Need to find out how to extent the codegenerated types with my own.
• Would need to use capnproto's internal native formats instead of Rusts.
• Good versioning...

JSON?

• I don't like JSON.
• It's fairly well known and supported.

Enums vs "strings"?

• Strings much more waste on the wire. Higher parsing overhead.
• Strings allow for custom types. Could just add a custom type enum that has a string.
• Enums could be 'backwards compatible' if you just ignore anything you don't understand.
• Strings wouldn't have to be predefined. But they would have to be used so defining them would be best anyway.

Categorise messages by type, or one global type for all messages?

• Categories could make it easier to ignore messages that have nothing to do with the service.
• One global type would be much easier to implement.
• Categories might be eaiser for reading documentation. But might be harder too as they might end up spread around.
• Maybe one global type with 'soft categories', ie categorise them based on the name but have one giant enum.

ASync

Look into using tokio for async.

Daemonization

2 libraries. One doesn't do Windows but seems better?

knsd/daemonize - Docs - No Windows afaik.

IPC

Servo has an ipc-channel crate. Doesn't do Windows yet.