From 4c56b955a17101627edd2b8fae077fdcf6086c35 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 7 May 2020 20:05:47 -0400 Subject: [PATCH] fold plan into readme --- README.md | 9 +++++++++ plan.txt | 23 ----------------------- 2 files changed, 9 insertions(+), 23 deletions(-) delete mode 100644 plan.txt diff --git a/README.md b/README.md index 32deb4b70..d5efd9008 100644 --- a/README.md +++ b/README.md @@ -102,6 +102,15 @@ tor-proto of the Tor protocol. Underdocumented, too big, needs refactoring. +## Intended architecture + +I'm hoping to have small, optional, separable pieces here. For everything +I'm writing, I'm hoping it can go behind a configuration flag. + +I'm also hoping to focus on everything that _isn't_ the network first. I'd +like as little code as possible to actually read and write to the network, +and as much code as possible to pretend that the network doesn't exist. I +hope this will make everything easier to test. ## Licence diff --git a/plan.txt b/plan.txt deleted file mode 100644 index 90fa8f953..000000000 --- a/plan.txt +++ /dev/null @@ -1,23 +0,0 @@ - -be agile in use of other crates, but kinda flexible in main coding. - -guess those mean the same. - -instead, "make sure our dependencies on particular implementations of things -are not hard to replace", and "assume we will refactor or rewrite everything -we do." - - -========== - -what architecture am I aiming for? I'm hoping for a layer that is -no-network, that doesn't even have a "network" as a thing in it. That means -it's going to have to have lots of encoding/decoding stuff, and maybe the -crypto, and possibly it can handle a little state, but big state will be hard - -Hm. This could actually help though. There are circuits and streams and -channels and they none of them need to actually "connect" until a different -layer. That would kinda rock, even. - - -