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.
• Hierarchy of caches.

Flow

• Look for local gateway service. (IPC/PidFile).
• If found connect to that local gateway service.
• Otherwise spawn local gateway service (Would make sense for this to be a separate binary).

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. 2 don't do Windows.

• knsd/daemonize - Docs - No Windows afaik. Recent updates (Oct 15th 2016).
• bozaro/daemon-rs - Docs - Example - Last update a year ago.
• swizard0/unix-daemonize - crates.io - A Year Ago.

• Daemons as plugins? Possible to update daemon's at runtime?
• Separate services provided from 'daemon'. One daemon can support multiple services in a single process. Could act as a proxy/gateway.
• mnds? - For networked services...

Services

• A service to list the services.
• A login service.
• A key/value look up service (needs some kind of security to ensure you can lookup that key).
• A name/value lookup service.
  • Security again.
  • Different people might get different results too... Ie... list_of_projects_I_can_edit.
  • Maybe list_of_projects_that_<USERID>_can_edit and use security to limit it to <USERID> (or admins). Could also work with GROUPS.
  • Should this return the actual data? Or should it return a hash
    • Any response should probably also send the data (Pipe lining).
    • Or automatically forward the request onto the key/value service and have it sent as a separate response?
    • What about dynamic/lazy evaluation? Don't want to keep all possible values around. Don't want to dump temporary crap in the hash store.
    • Give the client a 'ticket', if the response isn't returned in time, handle that. The ticket can be used with dynamic data returned.
• A service to get a list of projects.
• p2p runtime modification requests "Move <OBJECT_ID> to position <POSITION>". Once again needs security.
• Pub/sub? How can I know when the project I'm working on is modified by another user. What about when I only want the things I am near.

IPC

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