<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Joshua Cranmer 🐧 wrote on 24.04.2017
02:30:<br>
</div>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
I worry that the options here are "typescript" or "no static
typing, ever"</blockquote>
<br>
Obviously, that's not our only choices. As I already mentioned,
there is "closure compiler", somebody on maildev suggested that.<br>
<a class="moz-txt-link-freetext" href="https://github.com/google/closure-compiler">https://github.com/google/closure-compiler</a><br>
<a class="moz-txt-link-freetext" href="https://developers.google.com/closure/compiler/">https://developers.google.com/closure/compiler/</a><br>
There are others, e.g. Flow. I haven't looked into it at all, and
I'd like to have some opinions from people that have worked with
several systems and can tell us advantages and disadvantages.<br>
<br>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite">and I think I would personally lean towards the
former. Compilation steps aren't all that annoying.<br>
<br>
<blockquote type="cite"
cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com">
<blockquote
cite="mid:242e6c07-4cff-f9b3-8664-ceebbae9becc@gmail.com"
type="cite"> think that establishing tests against a few open
source server implementations with common data setups in
Docker containers is the best way to test these components<br>
</blockquote>
<br>
Yup, that's a nice idea. But nothing I'd want to run on my
machines. I'd want to trigger a "try" build and test server for
that. Or just land and see whether it passes (see above).<br>
</blockquote>
<br>
The ability to run tests on your local machine is something that I
consider, as a developer, non-negotiable.</blockquote>
<br>
Yes, agreed. I didn't mean to say you cannot. I just said I would
not want to be forced to do that, but I'd personally prefer a
service, and we should have such a service for such tests that are
either long-running or complex to set up. Of course you should be
able to run such Docker tests on your machine.<br>
<br>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite">If you've been reading today's IRC backlog, you'll see
some painful testing happening where the developer in question
doesn't have access to the thing being tested--and when you have
40-minute wait-for-results-oops-I-fat-fingered-a-variable-name
cycles</blockquote>
<br>
I've been in the situation myself where my change worked on my
machine, but failed on CI. Of course these were badly written tests
(of somebody else). But to debug them, I need to be able to run them
on my own machine. That's a matter of course, yes. It's a necessity.<br>
<br>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite"> <br>
<blockquote type="cite"
cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com"> <br>
* There might not be one single solution for all DB needs in
TB:NG. It may differ from case to case, so we should evaluate it
with specific cases where we need DBs and why and what the
requirements are. You probably have some cases in mind, so why
don't you just dump your brain somewhere?<br>
</blockquote>
<br>
I have an old start at <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="https://old.etherpad-mozilla.org/tb-new-db-api"><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>
<br>
Can you please document your ideas somewhere on the wiki and post
the link here? I would have gone for per-folder DBs, so I'm
intrigued by your comment and your rationale. Also your other
thoughts about DB implementations, where DBs are necessary, and how
the APIs to the DB and the component should look like as a
consequence.<br>
<br>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite"> <br>
<blockquote type="cite"
cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com">This
is more detail about APIs and implementation that we should
discuss on this thread, or even at this time.</blockquote>
</blockquote>
<br>
(Funny, I made a 1-character typo here that completely inverts the
meaning of the sentence. I meant to say: "more detail ... *than* we
should discuss on this thread".)<br>
<br>
<blockquote
cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
type="cite">[API to open a folder, based on DB]<br>
<br>
This means that the API design needs to start from the assumption
that "a current list of all messages in the folder" is not
something that should be presumed to exist as an in-memory
representation which means filtering even a conceptual list has to
let the filter be expressed in some manner that lets the query be
passed down to a DB layer (i.e., not a generic JS function
parameter). As you say in other messages, the key to performance
is not doing things that don't need to be done, and getting a list
of 1M messages so you can show 20 of them on the screen is an
excellent example of failing that criterion.</blockquote>
<br>
That's one way to look at it, but there are other criteria. I can
accept a small delay when opening a folder, but I cannot accept any
delay whatsoever during scrolling. My tolerance for scrolling delays
is what I eyes won't notice anymore, somewhere in the area of 20ms.
Essentially, as soon as I can *see* a delay when scrolling, it's
tripping me off, because it breaks the physical metaphor and visual
expectation we have from reality. Even if it's fast enough 95% of
the time, but there's a slight delay every 2000th message, it would
feel like jitter, and would feel like I'm stumbling. It's the same
thing as with virtual reality: It must be smooth *always*, otherwise
you get dizzy. For scrolling, it's as disconcerting as with VR, but
a little bit of the same, for the same reasons. I don't mean
Apple-style "smooth scrolling", but about avoiding visible delays.<br>
<br>
Loads from the drive or network are non-predictable. The drive may
be busy, or the DB implementation needs longer to find certain
parts, and some lookups take longer than the 20ms. And then you get
jitter in the middle of scrolling. For me, that's worse than a delay
when opening the folder. You're essentially asking for
"delay-loading lists". I've seen such implementations in some apps,
and they are deeply disconcerting for me, and they feel slow to me.<br>
<br>
I think 1 million emails in a folder are an edge case. We should not
redesign everything for edge cases, as that will have costs in
design and implementation time, and might cause other disadvantages.<br>
<br>
That said, you're mentioning interesting ideas. I'd be mostly
interested in supporting them with virtual folders and searches.<br>
<br>
I'll give it some thought.<br>
<br>
Ben<br>
</body>
</html>