Vision for Thunderbird
ishikawa at yk.rim.or.jp
Thu Feb 1 17:46:34 UTC 2018
I agree that workflow is very important for me, too.
There are so many topics which I can't tackle right now.
So below, I also focus on addons only.
On 2018/02/02 2:21, R Kent James wrote:
> On 2/1/2018 4:13 AM, Gervase Markham wrote:
>> On 31/01/18 20:20, R Kent James wrote:
>>> what would Thunderbird need to look
>>> like for it to be a major player in the email world?
>> Is that an achievable goal? People _like_ webmail. For many or even most
>> people, it's probably the right choice - accessible from everywhere and
>> anywhere, no setup required. Would it not make more sense for
>> Thunderbird to be focussed on those users for whom webmail doesn't work
>> (e.g. those who need good offline support)?
> It seems to me an odd argument, that because people like webmail we
> should not try to provide a webmail offering.
> The issue for me is really workflow. I have three devices I use to
> access email - an Android phone, a Surface tablet, and a large "laptop".
> If all I need is to read and delete email, sure no problem. But as soon
> as I try to use any advanced Thunderbird workflow techniques - tags,
> archiving, addons like Quicktext, bayes junkmail - I quickly find that
> they are not practical because these techniques are not supported
> seamlessly in my other devices.
Agreed. A common workflow on platforms is very important.
I use linux and windows all the time. (Shying away, or intentionally
staying from smartphone/pad environment right now for a few reasons.)
> Now as you hinted later it might be possible to provide a unified
> workflow experience by, say, Thunderbird somehow adapting existing
> mobile and web solutions and working to provide a unified workflow by
> addons or forks to those apps. That also though adds significant work.
> The technology to use JS/HTML as a unifying codebase across multiple
> platforms has evolved tremendously in the last few years. If Thunderbird
> undertakes to rewrite major portions of their codebase using that, IMHO
> it would be a strategic error to not seriously investigate whether it is
> possible to leverage that codebase across all modern platforms to
> provide a unified workflow experience, and ideally compatible UI.
I think with a portable UI-toolkit library, it is possible IN PRINCIPLE:
we have to cope with the screen size differences, etc.
Even under linux, when I moved to 4K display, suddenly the UI is so
warped, some apps are hard to use now until the apps have options to
allow the users to choose the font sizes for UI.
WHETHER the UI toolkit library used by TB is portable is something I
It strives to be, but I don't know how effective.
>>> 2) Protocol. ... both open protocols (IMAP, POP3, and SMTP for email,
>>> ... as well as
>>> proprietary protocols.
>> Is this just because no-one has put the work in, or because these
>> protocols are proprietary, undocumented and regularly changing? If it's
>> the latter, again, trying to go after that would be a massive resource
> I currently target an 11 year old version of Exchange Web Services, that
> is well documented and still works in new Exchange Servers. I am not as
> familiar with the Google protocols, but I suspect they are also
> similarly robust and well documented. This is not reverse engineering.
>>> Should we re-prioritize our efforts toward
>>> accomplishing the goal of reliable, convenient end-to-end security?
>> People have been trying to make PGP (or other secure) email reliable and
>> convenient for 20+ years, and a growing set of cryptographers are coming
>> to the conclusion that it simply can't be done...
>> Given that, I wonder whether having encryption support as a
>> (well-integrated) addon might actually be the right model.
> Understand that I am not arguing in favor of an emphasis on this, but ...
> If you believe that the major focus of Thunderbird should be offline
> email support with the corresponding advantages in privacy and ownership
> of data (and the loss of things like email search in webmail), then you
> are 80% of the way toward already making the tradeoffs necessary to have
> a focus on end-to-end encryption. You really do not finish the job
> without making sure that encryption is part of the offering.
Addons: Publish a reasonably rich set of API's and offer them for the
next five years: if the API needs to be changed, document the change
and support the transition.
In this sense, don't offer an API that would not be supportable after
the next two year or so.
We have seen the fiasco with FF losing many addons.
> As for addons, as a technology they could be part of a means to control
> complexity by offloading major pieces of functionality only used by a
> minority of users. But a serious, mission-critical app like an email
> program needs to agree what are the core capabilities that will be
> guaranteed maintained as part of new releases. If we rely on, say,
> Enigmail as a core part of our offering, then we do not ship a new
> release of Thunderbird until that addon is tested and working in the new
> version. So functionality could be done through addons, but a major
> addon like Enigmail IMHO is going to struggle to keep up without some
> sort of financial backing. That could be done through commercial
> partners, but we have frankly not known how to related to such partners
> in the past (nor has Firefox).
> I've proposed in the past some sort of concept of "supported" addons,
> where we would have a more defined partnership with addon authors to
> define expectations so that users could rely on these addons as optional
> but core offering of our product. Right now though addon support is
> fairly hit and miss, so if you rely on addons for core capabilities,
> then every major update of Thunderbird causes grief. If I was an
> organization looking to Thunderbird as a recommended offering, and I
> relied on several key addons as part of that, I would not have any
> confidence in the current model.
Expectations : offer reasonably rich set to access e-mail messages in
somewhat abstract manner to avoid disruption caused by
micro-implementation level differences.
Rely on the addons: offer the high-level API for a long time.
Abstraction when published API is designed will help.
(This may even mean that we put another layer of abstraction between the
class model used in the core implementation.)
Hit and miss.: Don't pull the API off the published list seemingly at
Just my two cents worth.
> tb-planning mailing list
> tb-planning at mozilla.org
More information about the tb-planning