true. Is this something you're doing?
-
-
Replying to @jaffathecake
saving the version in IDB would require a fully serialized transaction or, I guess, could be done with optimistic locking.
1 reply 0 retweets 0 likes -
Replying to @cramforce
you need to be doing that anyway, since the client can outlive the service worker
1 reply 0 retweets 0 likes -
-
Replying to @cramforce @jaffathecake
all we need is an unreliable, fast key value store like localStorage with promises :) IDB always feels like starting a tractor
2 replies 0 retweets 2 likes -
Replying to @cramforce
do we have data for that? Wonder how slow idb is for key-val and if that can be fixed
1 reply 0 retweets 0 likes -
Replying to @jaffathecake
will try to get data. But writing to flash with fsync on a crappy Android cannot be fast.
1 reply 0 retweets 0 likes -
-
Replying to @jaffathecake
only at a good time if there are no reliability guarantees.
1 reply 0 retweets 0 likes -
Replying to @cramforce
you could build this on top of shared worker (if we had it in serviceworker). Would be interesting to see the perf difference
1 reply 0 retweets 0 likes
: all of this can be answered with data. @inexorabletash to the rescue!
-
-
Discussion on flush control: https://github.com/w3c/IndexedDB/issues/50 ….
1 reply 0 retweets 0 likes -
Replying to @inexorabletash @slightlylate and
We should also be smarter and prime IDB on SW start (if we notice it's used).
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.