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.
• Runtime, inmemory stuff. For example, "Move <OBJECT_ID> to position <POSITION>". "<AVATAR_ID> is at <POSITION>.". Once again needs security. Other users shouldn't be able to view/modify things they don't have access too such as other users locations. Projects they don't have permissions to view/edit, etc...
• 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?
• Lock/unlock service. For editing.

• 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.
• What about p2p?

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.
• Client's should reject requests that don't originate from the central authority (but can come from different IP addresses).
• Client's can't view things they don't have permission to see.
• Client's can't modify things they don't have permission to modify.
• Could use/require digital signatures. Players in a p2p game could be proven to have cheated if other players/the_server disagrees with their messages.
• Some kind of access control lists? For data? For RPC functions? Some kind of dynamic ACLs?
  • I'm <CLIENT_ID: NORMAL_USER>, I need to BE_ALLOWED to see my list of my projects.
  • I'm <CLIENT_ID: HAXOR>, I need to BE_DENIED a list of <CLIENT_ID: NORMAL_USER> projects.
  • I'm <CLIENT_ID: SERVER_ADMIN>, I need to BE_ALLOWED to see a list of <CLIENT_ID: NORMAL_USER>'s projects. Or all projects. I have physical access so I can basically do what I want (unless encryption is used)...
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_ALLOWED to see a list of <GROUP_ID>'s projects.
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_DENIED list of <CLIENT_ID: NORMAL_USER>'s projects, even though they are in my group.
  • I'm <CLIENT_ID: GROUP_ADMIN>, I need to BE_ALLOWED to see a list of the group projects <CLIENT_ID: NORMAL_USER> is in.