<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/22/17 8:59 PM, Ben Bucksch wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
I don't like compiling/transpiling JS. I like linting and optional
compilers.<br>
<br>
closure-compiler might be an option, because it's optional and
could be applied only on release or as lint step.<br>
<br>
Other suggestions?<br>
</blockquote>
<br>
As far as I'm aware, TypeScript is the only commonly-used thing for
typing JS. It's probably not too hard to make an optional typing
system that we can check using a static checker--but trying to
invent our own JS type system will definitely be one of those things
that drives contributors away far more than anything else I propose.
I worry that the options here are "typescript" or "no static typing,
ever", 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. 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, that is
going to crash developer productivity. Having integration tests
largely be against targets that I can easily test with on my machine
is quite superior, IMO.<br>
<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 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>
<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. But your question was valid
and important, so I wanted to answer. I hope this removes your
concern.<br>
</blockquote>
<br>
Honestly, no. I'm concerned about performance, and in terms of
database performance, it is insanely hard to beat Mork (at least for
accessing via primary key only). Mork is basically a hash table of
row ID -> hash table of key -> value stores, and all strings
are interned (which means matching is simple 1-cycle integer
comparison, not dozens-cycle string comparison). A JSON file would
pretty much be like mork, except string values aren't going to be
interned, and the keys will only be interned if there's shape
homogeneity (which we'll lose if we allow arbitrary keys in the hash
table like the database does now)--in other words, JSON-backed
database is going to show somewhat worse performance characteristics
than our current mork databases do. And unfortunately, we already
know that we have performance issues with mork--which means the
problem isn't in the implementation, it's in the approach.<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. It's worth noting that this use case is explicitly
something that came up as "why writing this in HTML/JS is a bad
idea" on the Hacker News post about the rewrite-in-JS tb-planning
post.<br>
<blockquote type="cite"
cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com"> <br>
Ben<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>