On 2017-03-27 3:30 AM, Henri Sivonen wrote: >>> But when (according to doing a Google Web search excluding mozilla.org >>> and wading through all the results and by searching the JS for all >>> AMO-hosted extensions) the only out-of-tree spell checkers use >>> libvoikko, why involve Web Extensions at all? Why wouldn't we dlopen >>> libvoikko and put a thin C++ adapter between libvoikko's C API and our >>> internal C++ interface in-tree? That would be significantly simpler >>> than involving Web extensions. >> >> Is that different than what I suggested above in some way that I'm >> missing? > > I thought you meant that Web Extensions were your primary choice if > they could load code into the parent process.
No, that's not what I meant. > The main problems I see are: > 1) Right now the libvoikko distribution point is without https. > (Fixable with Let's Encrypt.) > 2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there > was a crasher bug in the library. (I'd expect the distros to take care > of pushing an update in the Linux case. It's the same situation with > e.g. PulseAudio and Gtk anyway.) It is also untrusted and unsigned code and can cause security and unstability issues. We have done a lot of work to remove all such code from our parent process. I don't think it's useful to make an analogy between this code and things like gtk. > On Sat, Mar 25, 2017 at 8:48 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: >> Another option would be talking to the maintainers of libvoikko and >> seeing if they would be open to maintaining the Mozilla bindings, in >> which case I think we should even consider doing something like what we >> do to download the OpenH264 binary at runtime when we need to. We could >> even build and sign it in the infrastructure ourselves if we imported it >> into the tree, with task cluster this is possible today with a super >> simple shell script (well, at least the building side of it!). > > If we are willing to do the engineering for that, that would be great! > (Of course, just putting libvoikko into libxul would be simpler, but > would cost an added 250 KB in libxul size for everyone who doesn't > need libvoikko.) That's not an option. 250KB for essentially dead code for most of our users is too much. > The situation with the Tracking Protection data suggests that we are > OK with GPLed run-time downloaded data files even though not code. > Have I inferred the licensing position correctly? That is, if we > distributed libvoikko under MPL 1.1, would we be OK with also > distributing and autodownloading GPLed dictionary files? > >> We >> basically need someone to sign up for maintaining it, since I doubt that >> MoCo will prioritize supporting a whole new spell checking backend for 2 >> new languages, but I think we can do a lot to help. > > I wouldn't expect MoCo to sign up to maintain libvoikko itself, but > the glue code needed between mozISpellCheckingEngine and libvoikko is > *extremely* thin: > https://github.com/voikko/mozvoikko/blob/master/components/MozVoikko2.js > (most of that code is jsctypes and XPCOM boilerplate; the code that > would need to be rewritten in C++ is almost nothing except trivial > forwarding to C.) The mozISpellCheckingEngine interface should be considered very unstable and subject to change in the very near future (possibly Firefox 55). In fact in bug 1303749 we may break it by moving the spell checking to happen in a background thread, and then there may be no scriptable interface to it any more. It may still be possible for them to provide a native library to us that we can load on the background thread and call into but it may require code changes on their side as well as our side to get that to work properly. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
