docs update

doc/FRAGMENTS.md

@@ -6,10 +6,40 @@
         - FragmentId
         - EventIndex
  - write fragmentStore
+    - load all fragments
+    - add a fragment (live on limited sync, or /context)
+    - connect two fragments
+    - update token on fragment (when filling gap or connecting two fragments)
+
+    fragments can need connecting when filling a gap or creating a new /context fragment
  - adapt timelineStore
+
+    how will fragments be exposed in timeline store?
+        - all read operations are passed a fragment id
  - adapt persister
     - persist fragments in /sync
     - load n items before and after key
     - fill gaps / fragment filling
  - add live fragment id optimization if we haven't done so already
  - lets try to not have to have the fragmentindex in memory if the timeline isn't loaded
+    - could do this by only loading all fragments into index when filling gaps, backpaginating, ... and on persister load only load the last fragment. This wouldn't even need a FragmentIndex?
+
+
+so a gap is two connected fragments where either the first fragment has a nextToken and/or the second fragment has a previousToken. It can be both, so we can have a gap where you can fill in from the top, from the bottom (like when limited sync) or both.
+
+
+
+
+also, filling gaps and storing /context, how do we find the fragment we could potentially merge with to look for overlapping events?
+
+with /sync this is all fine and dandy, but with /context is there a way where we don't need to look up every event_id in the store to see if it's already there?
+    we can do a anyOf(event_id) on timelineStore.index("by_index") by sorting the event ids according to IndexedDb.cmp and passing the next value to cursor.continue(nextId).
+
+so we'll need to remove previous/nextEvent on the timeline store and come up with a method to find the first matched event in a list of eventIds.
+    so we'll need to map all event ids to an event and return the first one that is not null. If we haven't read all events but we know that all the previous ones are null, then we can already return the result. 
+
+    we can call this findFirstEventIn(roomId, [event ids])
+
+thoughts:
+    - ranges in timeline store with fragmentId might not make sense anymore as doing queries over multiple fragment ids doesn't make sense anymore ... still makes sense to have them part of SortKey though ...
+    - we need a test for querytarget::lookup, or make sure it works well ...

doc/architecture.md

@@ -18,7 +18,7 @@ let fragment := {
     id: number
     previousId: number?
     nextId: number?
-    prevToken: string?
+    previousToken: string?
     nextToken: string?
 }
 ```
@@ -27,7 +27,7 @@ let fragment := {
 
 `Room`s on the `Session` are exposed as an `ObservableMap` collection, which is like an ordinary `Map` but emits events when it is modified (here when a room is added, removed, or the properties of a room change). `ObservableMap` can have different operators applied to it like `mapValues()`, `filterValues()` each returning a new `ObservableMap`-like object, and also `sortValues()` returning an `ObservableList` (emitting events when a room at an index is added, removed, moved or changes properties).
 
-So example, for the room list, `Room` objects from `Session.rooms` are mapped to a `RoomTileViewModel` and then sorted. This gives us fine-grained events at the end of the collection chain that can be easily and efficiently rendered by the `ListView` component.
+So for example, the room list, `Room` objects from `Session.rooms` are mapped to a `RoomTileViewModel` and then sorted. This gives us fine-grained events at the end of the collection chain that can be easily and efficiently rendered by the `ListView` component.
 
 On that note, view components are just a simple convention, having these methods: