MailExtensions API

Axel Grude axel.grude at gmail.com
Tue Jun 5 11:58:31 UTC 2018


Dear Ben,

please involve Add-ons / Extension authors in the discussion. I think we will need 
meetings, this can't just be hashed out on the mailing list.

I agree that expecting Thunderbird Community members (or Add-ons Extension authors) to 
implement missing APIs for free is a little unrealistic. One reason I write highly 
complex Add-ons is because Thunderbird is missing crucial functionality, and this is 
way way harder to do on the lower (patch Thunderbird) level.

I still believe Thunderbird being an open source Javascript based xulrunner 
environment is it's biggest assets against many other mail clients. It is also truly 
in the spirit of on source that there are no restrictions as to what an Add-on may 
add. Firefox removing this without an adequate replacement betrays that spirit of 
openness.

Let's collaborate!

Axel

*Axel Grude <mailto:axel.grude at gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders 
<https://addons.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/>, 
quickFilters <https://addons.mozilla.org/thunderbird/addon/quickfilters/>, 
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys 
<https://addons.mozilla.org/thunderbird/addon/zombie-keys/>, SmartTemplate4 
<https://addons.mozilla.org/thunderbird/addon/smarttemplate4/>)
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email 
productivity tips Get Thunderbird!
> *Subject:*MailExtensions API
> *From:*Ben Bucksch <ben.bucksch at beonex.com>
> *To:*Tb Council; Tb-planning
> *Sent: *Tuesday, 05/06/2018 12:49:49 12:49 GMT ST +0100 [Week 23]
> Hello TB Council,
>
> I had asked quite a while ago whether I could be hired to work on the architectural 
> foundations of the Thunderbird future. In the Council, with feedback from other 
> Council members, we had together decided to use the address book as test bed. That 
> would allow to iron out the framework details on how to implement the foundation, 
> from how backend modules are loaded (JSM, or require(), or ES6 modules, or Electron 
> modules, or what have you) and backend<->frontend communication (given that each 
> window might run in its own process, and we need shared data, that's far from 
> trivial), over XUL overlay replacements, to localization and to widget sets. Now, a 
> new topic just came up:
>
> Firefox 45 killing bootstrapped/restartless addons. That kills pretty much all of 
> our existing extensions. We have to decide how to proceed. Either we maintain the 
> addon manager code to keep them alive, or we create a MailExtensions API. The latter 
> is not at all trivial, it's a completely new architecture.
>
> I would like to propose to design such a MailExtensions API. I would take somelike 
> STEEL, at least this level of abstraction in the API. Then, make a similar (not 
> identical) API as part of the WebExtensions API. This would allow to implement some 
> functions in Thunderbird.
>
> An open question is how such extensions can hook up in the Thunderbird UI. The 
> problem is much harder than in the browser. In the browser, you only have toolbar 
> icons, and that's it. In Thunderbird extensions, we want toolbar buttons, but also 
> mail header UI, and maybe a (single) place to add menu items. Still, extensions need 
> to add new mail account types, implement content decoding for PGP, new UI like 
> gmail-style "Conversations". I personally depend on an extension for my phone 
> provider that adds a button next to each phone number in the address book and lets 
> me call the person with one click. How to continue to support all that kind of UI 
> hookup needs to be worked out. I could imagine that we define certain data types, 
> like "mail window", "folder", "message header", and "address contact" or "phone 
> number", and the extension can add a little UI there, e.g. a button with icon, or a 
> text. Thunderbird would then be able to place this UI itself, not the extension 
> choosing the exact place. The list of UI places available would be relatively small, 
> maybe 10 or 20. The extension UI would then get a reference to the object next to 
> which it is placed, so that it can operate on that data, e.g. call that phone 
> number. In other words, we invert the control: The extension says "I want to add 
> something to phone numbers", and Thunderbird places the extension UI, and gives a 
> reference to the contact and phone number, instead of the extension picking the 
> exact UI place and picking the data from some internal Thunderbird window data 
> structures.
>
> Exposing some high level data APIs, like accounts, folders, messages, and allowing 
> to add account types and content handlers, as well add exposing a certain number of 
> UI hookup places, all with a well-defined API, would dramatically reduce the API 
> surface that Thunderbird exposes, and allow extensions to continue to work even in 
> face of drastic chances in Thunderbird.
>
> In fact, if the extension API is done well enough and abstract enough, it might be 
> possible to even let a completely new re-implementation of Thunderbird based on HTML 
> be able to support the same extensions, with minimal or no changes, similar to how 
> Firefox supported some Chrome WebExtensions. However, in order to achieve that, the 
> API needs to be abstract enough and well thought out.
>
> I am proposing to attempt that. However, it's a big project, and I would need to be 
> hired for that.
>
> Ben
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20180605/5ad1425d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20180605/5ad1425d/attachment.png>


More information about the tb-planning mailing list