<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
<div id="smartTemplate4-template">
<p>Dear Ben,</p>
<p>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.</p>
<p>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. <br>
</p>
<p>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.</p>
<p>Let's collaborate!<br>
</p>
<p>Axel<br>
</p>
<style type="text/css">
.myName {
text-shadow: 1px 1px 2px #DDD;
transition:font-size 0.5s;
}
.myName:hover, .myName a:hover
{ font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
.moz-signature {opacity: 1.0 !important;}
.myName a { cursor: pointer !important; transition:font-size 0.5s;}
.myLogo {
transition: all .4s ease-out;
}
.myLogo:hover {
transform: scale(3) translate(-30px,-5px);
}
#mySignature, :not(blockquote) #mySignature {
background: rgb(230,240,163);
background-image: linear-gradient(to bottom, rgba(230,240,163,1) 0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1) 51%,rgba(219,240,67,1) 100%);
color: #444;
box-shadow: 4px 4px 9px -2px rgba(0,0,0,0.65);
border-radius: 0.7em; padding: 0.8em 1.2em;
border: 1px dashed #8080A0;
font-size: 11pt !important;
font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;
width: 65%;
}
.AddonList a {
color: #666666;
font-size: 10pt !important;
}
</style>
<div id="mySignature"> <b class="myName"><a
href="mailto:axel.grude@gmail.com">Axel Grude</a></b> <br>
Music Production and Composition <br>
Thunderbird Add-ons Developer <span class="AddonList">(<a
href="https://addons.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/">QuickFolders</a>,
<a
href="https://addons.mozilla.org/thunderbird/addon/quickfilters/">quickFilters</a>,
<a
href="https://addons.mozilla.org/firefox/addon/quickpasswords/">QuickPasswords</a>,
<a
href="https://addons.mozilla.org/thunderbird/addon/zombie-keys/">Zombie
Keys</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/">SmartTemplate4</a>)</span>
<br>
Visit my <a href="https://www.youtube.com/c/thunderbirddaily">YouTube
Channel</a> for email productivity tips <img
style="margin-top: 1em; float: right; box-shadow: 1px 1px 2px
rgba(20, 20, 20, 0.4);" moz-do-not-send="false" class="myLogo"
src="cid:part8.F3B9B3D4.C18B28BA@gmail.com" alt="Get
Thunderbird!" height="15" width="94">
</div>
</div>
<div id="smartTemplate4-quoteHeader">
<style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>MailExtensions
API<br>
<b>From:</b>Ben Bucksch <a class="moz-txt-link-rfc2396E" href="mailto:ben.bucksch@beonex.com"><ben.bucksch@beonex.com></a><br>
<b>To:</b>Tb Council; Tb-planning <br>
<b>Sent: </b>Tuesday, 05/06/2018 12:49:49 12:49 GMT ST +0100
[Week 23]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:8d2b23cc-bb46-0dd3-5d3d-2914f0fd001e@beonex.com"
id="mid_8d2b23cc_bb46_0dd3_5d3d_2914f0fd001e_beonex_com" class="
cite">Hello TB Council,
<br>
<br>
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:
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
I am proposing to attempt that. However, it's a big project, and I
would need to be hired for that.
<br>
<br>
Ben
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
<br>
</blockquote>
<br>
<br>
</body>
</html>