<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 21, 2016 at 2:18 PM, Joshua Cranmer 🐧 <span dir="ltr"><<a href="mailto:pidgeot18@gmail.com" target="_blank">pidgeot18@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
At present, Thunderbird already uses two JS protocol libraries: JSMime and ical.js. I've also prepared a SASL library and I've poked away at an NNTP library that I want to try testing (to replace nsNNTPProtocol eventually) sometime this year; I've also poked a little bit at the <a href="http://whiteout.io" rel="noreferrer" target="_blank">whiteout.io</a> (now emailjs) libraries.<br></blockquote><div><br></div><div>I'd be especially interested in the NNTP library so we could finally enable Gloda on NNTP. I seem to recall the issue being somewhere in nsNNTPProtocol (or maybe a related class), and no one actually knowing quite how to fix it. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The standard testing environment for JS these days seems to be Mocha [3], and many of the libraries are using CommonJS-style assert for the tests.</blockquote><div><br></div><div>Don't even get me started about assert libraries in JS. They're all awful, especially the "expectation" interface that Chai uses. CommonJS-style asserts at least have the benefit of not being overly-cutesy. I prefer an interface more like Hamcrest <<a href="http://hamcrest.org/">http://hamcrest.org/</a>> or my own project, mettle (which is C++14, sorry) <<a href="http://jimporter.github.io/mettle/expectations/">http://jimporter.github.io/mettle/expectations/</a>>. I really wish something better existed for JS.<br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One plausible alternative is to use submodules, but my prior experience with build systems and release engineering has left me uncomfortable with having Thunderbird use more than 1 repository.</blockquote><div><br></div><div>Submodules are pretty annoying to work with, but in my experience, mainly because it's easy to forget that `git clone` doesn't pull submodules in. I'm not sure if releng has any significant issues with them, though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Another alternative is to do what is done for NSPR and NSS, and that is to effectively check in the entire repository in a subfolder and update that periodically [5].<br></blockquote><div><br></div><div>Vendoring the libraries like this is probably the most-reliable method (although using a package manager is probably doable too). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The biggest challenge, of course, is the sheer lack of a useful standard library in JS.</blockquote><div><br></div><div>Maybe someone needs to make Boost.js. :)<br><br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[3] Specifically, I (and apparently ical.js) prefer the tdd UI for this, which isn't the default. The only real difference is that the tdd uses suite/test for its function names, while the default uses describe/it.<br></blockquote><div><br></div><div>suite/test is better, I agree. describe/it is an extremely-strange wording and usually results in people trying to reword their tests to match the (English) grammar the names imply, e.g. `it("puts the lotion on the skin")`. That usually results in less-readable test logs in my opinion.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[7] I've ended up using MIT for these libraries, largely because it's smaller in boilerplate, I think it's a slightly less fearful license for third-party users, it's what the emailjs libraries used, and I'm not a strong believer in the weak copyleft that MPL is. I'll point out that ICAL.js is using MPL 2 and Gaia (including, presumably, Gaia Email) uses Apache.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Permissive licenses are fine by me. Personally, I'd much rather people be able to use my code than anything else.<br><br>Overall, this sounds like a good plan, and I think it's wise if we try 
to minimize the amount of new C++ code in Thunderbird while excising the
 existing C++. As much as I like C++, it doesn't seem to have a future 
in Thunderbird due to incoming Gecko changes.<br><br></div><div>- Jim <br></div></div><br></div></div>