Future Planning: Thunderbird as a Web App
kent at caspia.com
Fri Sep 18 17:39:48 UTC 2015
On 9/17/2015 3:20 PM, Sean M. Pappalardo wrote:
> The direction you outline makes sense to me and opens up some
> interesting possibilities. I just have a few questions.
> As a "web app," will Thunderbird still look and feel like a desktop
> one on desktop OSs? Will there need to be a hidden Web server process
> in the background? How much of a speed penalty will there be with JS
> vs C++ code?
> Will it be easier (even trivial, dare I say) to build Thunderbird as a
> native iOS and Android app once it's a Web app?
> Would it be possible to run Thunderbird as a cloud app too? I.e. the
> back-end on a Web server and front end usable by any modern browser?
> (Much like SOGo's Web interface:
Performance: is a major concern as others who have gone down this path
have encountered, and we see with JsMime and ical.js I think it will be
important that we not simple assume that the performance issues will be
solved by faster js, but we need to identify performance-sensitive areas
and a mitigation strategy. That might include using asm.js more
deliberately, or even proposing needed WebIDL components that are needed
to be developed and exposed to the web that solve critical performance
native iOS or Android: No this is not a goal or easier. If it were, we
would follow the path of Fennec, but that is not the plan here.
Thunderbird as a cloud app: This would not be a short-term goal. But we
might need to be open to this as a possibility when we design basic
protocols. For example, we will need to consider the path that transmits
information about messages to the front-end code. At the very least we
will be moving to make this async. At the same time, we might consider
if that same interface could be adapted to a cloud-based back end in the
future. You might, for example, use a cloud-friendly protocol like JMAP
to interface to your local message storage, so that a future cloud-based
app could be converted easily.
> If this is the direction things go, how will that affect my desire to
> add full LDAP editing? Should I wait until the application core is
> changed over first? Or will rewriting the Address Book module be part
> of the code conversion?
LDAP is a great example of how thinking might change. I think we have
discussed for years that LDAP code needs to convert to a standard,
non-binary library in the long run. I think that we should resist the
urge to try to adapt our existing C++-based library to support editing.
But if you are interested in LDAP, we would really, really appreciate
someone who would research available, license-compatible LDAP js
libraries, and adapt our code to use that. Editing should be added in
the context of that new library.
As for user interface, if you do a new UI you should consider using HTML
instead of XUL. This is already done in a few places in Thunderbird
code. See for example accountProvisioner.xhtml The js support for that
brings in many existing XPCOM-based Thunderbird js scripts, so you can
see that it is actually not as difficult as you might imagine to use
HTML instead of XUL.
More information about the tb-planning