Thunderbird as a Web App revisited
ben.bucksch at beonex.com
Sun Dec 20 12:14:29 UTC 2015
Robert Kaiser wrote on 20.12.2015 03:51:
> Ben Bucksch schrieb:
>> That runtime would need some features that a normal webbrowser does not
>> have. The absolute minimum that comes to mind is opening TCP sockets, to
>> allow IMAP/POP3 without proxying, and opening/saving files (even if only
>> in a certain directory on disk), to store emails persistently locally.
>> Probably I'm missing a few other things.
> Both exist in Gecko and have been implemented for Firefox OS (though
> file access through DeviceStorage is somewhat awkward). They may not
> be fully implemented on desktop platforms and/or enabled on Firefox
> but that is a gap that Mozilla wants to close from all I know.
I know. There are several potential runtimes:
* XULRunner (without using XUL, and XPCOM only for those few APIs I
* GeckoView in Android (offshoot of Fennec), with adding custom JS APIs
* NW using node.js
Either way, I would ship the runtime with the app, like Thunderbird
today ships Gecko with the EXE, and install and start it all together in
one go. Simply to make it easy for end users.
And also to avoid having to deal with 3 different HTML renderers in 15
different versions each (particularly on Android, where people still use
Android 4.0 etc.), and to official support them all. They still have
minor differences, and that's a major hassle in web dev. That would hold
To answer Paul directly: While technically possible to ship a server
with the app, there's no point in doing it either. It's just a further
indirection, so slower. And also additional trouble: if one of them
crashes or is closed, you need to ensure that the other is closed, too.
That's not as easy a problem as it sound, if you want it to work in case
of error situations. It's easier to build these few APIs directly into
the JS API of the runtime.
More information about the tb-planning