note updates

doc/- sync comes under session

@@ -1,3 +0,0 @@
- - sync comes under session
- - sessioncontainer/client orchestrating reconnection
- - 

doc/impl-thoughts/LOCAL-ECHO-STATE.md

@@ -0,0 +1,16 @@
+# Local echo
+
+## Remote vs local state for account_data, etc ...
+
+For things like account data, and other requests that might fail, we could persist what we are sending next to the last remote version we have (with a flag for which one is remote and local, part of the key). E.g. for account data the key would be: [type, localOrRemoteFlag]
+
+localOrRemoteFlag would be 1 of 3:
+ - Remote
+ - (Local)Unsent
+ - (Local)Sent
+
+although we only want 1 remote and 1 local value for a given key, perhaps a second field where localOrRemoteFlag is a boolean, and a sent=boolean field as well? We need this to know if we need to retry.
+
+This will allow resending of these requests if needed. Once the request goes through, we remove the local version. 
+
+then we can also see what the current value is with or without the pending local changes, and we don't have to wait for remote echo...

doc/impl-thoughts/RECONNECTING.md

@@ -66,7 +66,12 @@ rooms should report how many messages they have queued up, and each time they se
     NO: When connected, syncing and not sending anything, just hide the thing for now? although when you send messages it will just pop in and out all the time.
 
  - see if it makes sense for SendScheduler to use the same RetryDelay as Reconnector
- - finally adjust all file names to their class names? e.g. camel case
+ - DONE: finally adjust all file names to their class names? e.g. camel case
  - see if we want more dependency injection
     - for classes from outside sdk
     - for internal sdk classes? probably not yet
+
+
+
+
+thought: do we want to retry a request a couple of times when we can't reach the server before handing it over to the reconnector? Not that some requests may succeed while others may fail, like when matrix.org is really slow, some requests may timeout and others may not. Although starting a service like sync while it is still succeeding should be mostly fine. Perhaps we can pass a canRetry flag to the HomeServerApi that if we get a ConnectionError, we will retry. Only when the flag is not set, we'd call the Reconnector. The downside of this is that if 2 parts are doing requests, 1 retries and 1 does not, and the both requests fail, the other part of the code would still be retrying when the reconnector already kicked in. The HomeServerApi should perhaps tell the retryer if it should give up if a non-retrying request already caused the reconnector to kick in?