Joining forces vs. starting from scratch (was Re: Proposal to start a new implementation...)

Ben Bucksch ben.bucksch at beonex.com
Wed Apr 19 03:32:07 UTC 2017


Joshua Cranmer 🐧 wrote on 19.04.2017 04:30:
> On 4/10/2017 9:47 PM, Ben Bucksch wrote:
>> emailjs.org
>>
>>       o Implementations of MIME, IMAP, SMTP
>>       o Definitely need to look at this, potentially use it.
>>
>
> I did a writeup of the email.js SMTP implementation in comparison to 
> Thunderbird's current implementation two years ago (wow, has it really 
> been that long). The general conclusion is that it bakes in a lot of 
> assumptions that aren't really safe for general use (for example, 
> email messages are only ASCII body contents, or ignoring SMTP features 
> not found on gmail like delivery status notification). The response 
> from the email.js people was more or less "feel free to go ahead and 
> rewrite large portions of it to suit your needs", but there is a fair 
> amount of rewriting that has to be done there to make it more amenable 
> to some of the tasks to support.
>
> One of the issues that comes up when doing these sorts of libraries is 
> platform support. It turns out that the standard JS library is so 
> sucky you need a lot of little things to do useful stuff, and there's 
> a few components that end up getting needed to be shared between all 
> of the libraries. Doing the dump-this-ASCII-in-an-ArrayBuffer or 
> base64 conversion ends up cropping up in a lot of places, yet the 
> pieces are so easy that it's generally not worth the bother to create 
> an entire library with an entire dependency for just one thing. 
> Whatever we do, I strongly encourage some base utility libraries just 
> to avoid the fifteen-fold duplication of this stuff that will crop up 
> otherwise.

Yes, I see the same in other contexts, e.g. the UI, that there are not 
enough powerful APIs in JS. A lot is done with arrays. Using a slightly 
higher level API (e.g. collections, or streams/buffers) consistently 
across all the components would dramatically help. At least JS strings 
are Unicode :).

I think emailjs.org libs are a good starting point. I've merely started 
with emailjs, because of asutherland's endorsement, he worked with them 
a lot, and I respect him highly, so that was a good start. However, it's 
very likely that at some point, probably rather early, we'll find the 
libraries lacking and will adapt or rewrite them. Or we might find 
better existing ones.

That's not a problem, though. As long as we have good abstract 
high-level APIs, we can swap out the underlying implementation without 
problem. It the APIs are too particular, it's very hard, as you found 
with JSMime in current Thunderbird and Kent found with JsAccount.

Just case in point: As you might have seen in a few of my posts, I'm 
currently working on a little prototype for the Thunderbird successor. 
Nothing works yet, so I haven't shared it. I had started with my 
|Account| API and the IMAP and POP3 implementations that I had written 
in JavaScript a few years ago, and that were used in a commercial 
project, but are under MPL. I naturally started with them.

Then, last night, as a test, I rewrote the entire IMAP implementation, 
now using the emailjs.org IMAP library, to try that one out. And I was 
positively surprised. The API is straight-forward and works exactly as I 
expected. The overall design was very similar to what I had designed 
independently of them. I had the emailjs IMAP based implementation 
working within a few hours. It was easy to work with and worked straight 
away (modulo being unclear with SSL vs. STARTTLS, but many have that 
confusion). And, best of all, I didn't have to change my API even one 
bit. I could swap out the entire IMAP implementation and the rest of my 
code didn't need to change. This is because the API was sufficiently 
high-level and I had avoided leaking particularities of the 
implementation into the API. That's something that's impossible with 
current Thunderbird.

So, a) the emailjs libs are a starting point, for the MVP approach, and 
b) we're not stuck with it and can change implementations later as need 
arises. And most importantly it shows c) the importance of a good, clean 
API.

A lot hangs off good code design, framework and APIs: Fast progress, new 
contributors, maintainability, easily fixing bugs, adding features, up 
to extensions.

What you're saying about about consistent Buffer APIs across components 
goes into the same direction.

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


More information about the tb-planning mailing list