TheFramework: Difference between revisions
Jump to navigation
Jump to search
| Line 27: | Line 27: | ||
* Strings allow for custom types. Could just add a custom type enum that has a string. |
* 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. |
* Enums could be 'backwards compatible' if you just ignore anything you don't understand. |
||
===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== |
==ASync== |
||
Revision as of 00:39, 28 December 2016
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
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.
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?
IPC
Servo has an ipc-channel crate. Doesn't do Windows yet.