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... 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. Although If I'm in a group the first one would need to return the results of the 2nd for all the groups I'm in too.
  • 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 getting information about only the things I am near? Just have a name that points to a root hash with the project properties that gets updated continuously? Automatically pipeline the update to other users. Dynamic vs stored data?

• Maybe it's just a REQUEST/RESPONSE service. And some of those requests are for KEYS/VALUES. Others are for LOGIN(USERNAME, PASSWORD), etc... Dispatch to the appropriate internal service.

IPC

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

Security

• Client needs some way to know responses coming from other services are from the same central authority.