Invitation for technical discussion on next-generation Thunderbird

Ben Bucksch ben.bucksch at beonex.com
Mon Apr 24 13:27:42 UTC 2017


Joshua Cranmer 🐧 wrote on 24.04.2017 02:30:
> I worry that the options here are "typescript" or "no static typing, ever"

Obviously, that's not our only choices. As I already mentioned, there is 
"closure compiler", somebody on maildev suggested that.
https://github.com/google/closure-compiler
https://developers.google.com/closure/compiler/
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.

> and I think I would personally lean towards the former. Compilation 
> steps aren't all that annoying.
>
>>>  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
>>
>> 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).
>
> The ability to run tests on your local machine is something that I 
> consider, as a developer, non-negotiable.

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.

> 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

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.

>
>>
>> * 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?
>
> I have an old start at 
> <https://old.etherpad-mozilla.org/tb-new-db-api>, 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).

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.

>
>> This is more detail about APIs and implementation that we should 
>> discuss on this thread, or even at this time.

(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".)

> [API to open a folder, based on DB]
>
> 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.

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.

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.

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.

That said, you're mentioning interesting ideas. I'd be mostly interested 
in supporting them with virtual folders and searches.

I'll give it some thought.

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170424/64d8a232/attachment.html>


More information about the tb-planning mailing list