Might fly for passwords. This is something Taras has floated before:
lets use more in-memory flat files that are kept compressed in memory.
That would be in many cases much more compact than spinning up sqlite.
If I remember correctly, the average user has 500 passwords. Thats not a
big deal compressed. Bookmarks is 500-ish as well. History 5000-ish. We
can easily limit history for worst cases. I don't think people will have
thousands of passwords. But bookmarks might grow large for a lot of
users. On the other hand, we have to keep much of that in memory anyway
to actually display it (build the menu), so maybe huge-bookmark-list is
impractical on mobile anyway.
You might have a winner here. I am happy to hack up a compressed
hashtable backend for pouchdb. The problem is still that pouchdb itself
has no sync API, but we could probably hack that in there with
generators. Should we give this a spin?
Andreas
Gavin Sharp wrote:
On Fri, Jul 26, 2013 at 12:39 PM, Andreas Gal<[email protected]> wrote:
You answered your own question. If I store passwords in a pouchdb
replacing the current storage (which is very desirable and would
greatly reduce complexity), and I am inside searchLogin() and I am
supposed to immediately return a login, how do I do that from a
pouchdb that is async and only has async backends. I can spin the
event loop or I can block on pouchdb on a different thread. Both
approaches suck.
OK, I see (I didn't understand that that was what you were proposing).
The other alternative would be to keep an in-memory cache of passwords
(so we can return them synchronously, but keep the storage backend
async). I imagine that might not fly on mobile, though?
Gavin
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
