search

RootAccessOrg / TrickleEdit

TrickleEdit: Queuing edits to prevent flooding
MIT License
0 stars 0 forks source link

Storage mechanism #1

Open BobVul opened 7 years ago

BobVul commented 7 years ago

We need to store pending edits. This needs to be a reliable storage — it would be bad to lose edits the user has spent time writing...

Also need to store edits that failed to submit, for user action. Also maybe store a history of successful past edits.

There's an unlimitedStorage option that can be set in the manifest. We're storing very little data, but it appears that Firefox and Chrome only provide strong(ish) guarantees of not deleting data if the storage is declared persistent, which requires either a user prompt or unlimitedStorage be set.

There's two options for storage:

localStorage

This is possibly the better-supported one, as it exists as an extension API. It's also very easy to use. However, it is a very basic key-value store and requires the data to be serialised before storing. Possible efficiency impacts?

IndexedDB

More complex to use, but more powerful and probably faster too. Especially if the list of edits gets long. Not relational, but easier to simulate it than with localStorage.

Fleex255 commented 7 years ago

I would guess, but am not 100% sure, that the time spent looking up the data in local storage is drowned out by the time it takes to send the data across the network. Serialization should just be a matter of JSON.stringify and JSON.parse. That also probably won't meaningfully impact efficiency, especially considering that we're canceling the real edit submission at queuing time (saving the network trip) and submitting it later in the background.

If/when we get some central orchestration, queued edits could be stored on the server. There would be no shortage of storage capability and users would be able to make edits from one computer and publish them from another.

BobVul commented 7 years ago

With localStorage I'd either have to read everything into JS at once, or implement some custom indexing scheme on top. But reading everything is probably good enough for the PoC.

For performance, with localStorage is it's a synchronous API, and apparently at least Chrome will load the entire storage for that origin on page load. This means every page load will be slower, even if we never read from storage.

If it's only pending edits, that's not too bad. If an edit history is kept, it would just keep growing.

BobVul commented 7 years ago

Oh, one advantage of using localStorage is it can be synced (via Firefox/Chrome sync) with other browsers owned by the user, if that's wanted. Again, something for later.