Open harrisi opened 1 year ago
I could also potentially send events to my server rather aggressively and then when the app closes, consolidate and send them to the bookplayer api when a heartbeat is lost.
Also, since everything works offline, I need to queue events anyway. I should definitely start from this assumption.
Partially fixed by eaf7d997038fdf14c007113f5de50697b83e1865
Doesn't handle name changes, movements, speed, etc.
Thinking about how best to update metadata to keep things in sync without sending too much data. The two extremes are
(1) isn't great because it's far too many events. (2) is potentially nice since in a long session, all the previous states that don't matter won't get uploaded. If the user ends up having updates for 100 items in one session though, it can be a lot to send all at once. Also, there may be events that need to happen in a certain order. Handling (2) nicely across browsers is potentially an issue, but also it seems like it's easy enough to do some work before the tab is closed with visibilitychange.
An alternative for (1) is to periodically send events every
n
seconds. This is what the app does, withn=10
. For (2), the alternative is to send updates on every major state change, such as changing track, moving or renaming, adding files/folders.Are bookmarks a major event? (EDIT: yes.)