Invitation for technical discussion on next-generation Thunderbird

Magnus Melin mkmelin+mozilla at
Sun Apr 23 11:44:22 UTC 2017

On 4/23/17 4:59 AM, Ben Bucksch wrote:
>>  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).
Well tests should be runnable both ways: manually and on a try server. 
In practice it's extremely annoying to try to figure out something 
failing on try. You need the local version as well.

> That's a nice perspective. Most users won't care about LDAP or 
> Kerberos or S/MIME. OTOH, binary components are a major burden for 
> build and release, because they have to be shipping for at least 3 
> platforms, they should be C++ compiled from source (no executables in 
> the source repo, please!), which seriously ups the build dependencies 
> and hinders new devs.

While most things would be JavaScript, I doubt it's feasible to have a 
desktop application with no C++ at all.

> My point is just:
> * 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 would agree, in-memory type dbs/datastructures can get you pretty far. 
It remains to be seen what's best for each case.

> * Now is probably not the right time to make a project-wide decision 
> on which DB to use.

Yes, too low level for this discussion, but if we want to be webby (and 
we do) it's basically IndexedDB.

> More importantly, "JS Collections" 
> are going to be one 
> cornerstone of the API. The list of accounts, of folders, and of 
> messages, are all such collections. These collections are observable, 
> so there is not even a need for an explicit async API, but it comes 
> for free. 

Without looking too much on that proposal, it strikes me that if it's a 
good idea, why isn't that standard? I'd like to avoid doing 
non-standards things because it would sound smart on surface. If general 
of value, it would likely be common practice.

Another thing, React is probably the strongest contender for a framework 
to use (if we use a framework, and not just standard web components). 
But even if we don't use React per se, there are lessons to be learned 
from there, as their model semi-forces you to think very closely about 
internal data ownership. The common case for arrays, as arguments, is 
you splice them in the component constructor to get a copy, so you don't 
get to modify data owned by other components. This is what makes their 
data ownership clear and components non-entangled with each other.

If the collections were observable it appears you would get into an real 
mess with all of that.

> A local mail storage is obviously needed even for IMAP, and would not 
> change the folder API, just insert essentially insert a cache, on the 
> implementation level. I'm thinking of some sort of DB or JSON for the 
> headers and mbox or maildir for the content.

Speaking of cache, we want to make sure it's really working well in an 
offline first approach, and see what Service Workers can get us in that 
regard. This is an important part to build in from start to make it 
right, and will have potentially far reaching design implications since 
we need to leverage web technologies instead of trying to re-create e.g. 
caching ourselves.


More information about the tb-planning mailing list