<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/24/17 3:30 AM, Joshua Cranmer 🐧
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br>
I have an old start at <a class="moz-txt-link-rfc2396E"
href="https://old.etherpad-mozilla.org/tb-new-db-api"
moz-do-not-send="true"><https://old.etherpad-mozilla.org/tb-new-db-api></a>,
although that was mostly focused on a better way of representing
the current API in a more asynchronous manner. I've definitely
advocated in the past for even stronger changes (most notably,
per-account databases rather than per-folder databases, which I
think opens us up to better optimizations in cases like deleting
messages), but that's hard to retrofit in the current API
assumptions (again, assuming that loading a database gets you
O(instant) access to any message really cripples what you can do
in the DB design space).<br>
</blockquote>
<p>That's a very good read, although as you say, keeping a too much
baggage.</p>
<p>When thinking fresh, I think it helps a bit to look with one eye
on what the implementation would be in practice. Whatever route we
go we're fairly much tied to IndexedDB for... some things. What
things is open, but there are no other databases web compatible,
usable from workers, and also having an API full of Promises. <br>
</p>
<p>Since mork will need to go, we do need a replacement. There have
been a lot of talk about "wanted numbers" around these threads. Of
course we want performance, and it will be as good as it gets. If
the performance is not what we want, we need to tackle that. If
it's not about pure db optimization, it's a weigh-off against
something else (usually ease of access). But I'd still save the
talks of expected performance numbers for later.<br>
</p>
<p> -Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>