<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 26/09/2020 17:14, Klaus Buecher wrote:<br>
</p>
<blockquote type="cite"
cite="mid:c50c5961-7526-d841-c221-d8d8955b0990@optosolar.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
1) I think the main question is not about addon technology. What
we need to answer is:
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">*** do we commit to keep TB feature-rich? ***<br>
</span></p>
<p><br>
</p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">Whether we call it api, experiment, MX is
irrelevant. I and others have been able to mix MX and legacy
using experiments in one addon. So there are ways. I may have
ideas for other ways.</span></p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de"> But: Where do we want to go? Is
there a commitment to stay feature-rich? By the dev team, by
the council?</span></p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">I am standing for the council elections, and
this is one of the results I will push for: a commitment to be
able to add relevant features. Inside and outside of core,
maybe for specialised audiences only. If they are corporate,
they may have/may spend money.<br>
</span></p>
</blockquote>
<p>I'm finding your phrasing a little strange. On one hand you seem
to be asking should we keep Thunderbird feature rich, but then you
are implying that the only way we can do that is by add-ons. You
are then discussing the limitations of the WebExtensions in their
existing state. Both of which are biasing the question in my
opinion, when you also seem to be trying to keeping it unbiased
from the technology discussion.</p>
<p>For example, we could decide that we should forget about add-ons
and include everything we possibly can in the core. That is a
valid possible outcome of "do we commit to keep TB feature-rich?".
Obviously, there's a trade off of implementation and support
versus usefulness, complexity and maintenance.<br>
</p>
<p>I think there is a definite balance to be had, and where that
balance is might be hard to get exactly right, but I think
Thunderbird can allow feature-rich add-ons without needing to
allow add-ons to have access to absolutely anything within
Thunderbird itself.<br>
</p>
<blockquote type="cite"
cite="mid:c50c5961-7526-d841-c221-d8d8955b0990@optosolar.com">
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">2) If we commit to be feature rich, that
shifts the focus. It changes the question from "How long do we
have experiments" to "We have to close down experiments, what
access do you need for your features and how can we hopefully
provide it".</span></p>
</blockquote>
<p>I think the latter is the right question, I think mostly the
former has been asked as it is the question that's more obvious to
ask and add-on authors are mainly worried about timescales for
adapting. Now John is starting to work on a procedure for
proposing APIs, I think we can start to address the latter
question more.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c50c5961-7526-d841-c221-d8d8955b0990@optosolar.com"><span
style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">3) On the other hand, just look at the current
status of MX. These are features we can realise without
experiments:</span>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">MailExtensions:<br>
1 button (each for messenger, compose, messagedisplay)<br>
1 entry into tools menu (only into that menu, if that is now
working, or is it still a bug?)<br>
1 entry into a context menu. More convert into a submenu, but
not more than 6 are allowed (Why 6? </span><span
style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de"> If more is needed, why not? </span>TB's
main menues confuse us with up to 20 entries?).<br>
Can't open an external browser. <br>
Can't ... you name it. (</span><span
style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">Status bar message? Dropdown on send
button? Advanced search field? Extra column?, ...)<br>
</span>Can do ... some (admittedly, much more than earlier,
and thanks for that!! I see things are coming. E.g. changes in
81/82)<br>
</span></p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">To be honest, we can do some more in MX, but
the text shows there is still far to go. <br>
</span></p>
</blockquote>
<p>I don't think anyone has said the APIs are anywhere near
"complete". Some of these are inherited from the Firefox APIs, and
we haven't considered if they should be expanded yet. Others we
still need add-on authors to propose what's necessary - that's
what John is working towards at the moment.</p>
<p>I do think this needs help from add-on authors - for them to
transition and discuss what's missing, as well as providing code
to Thunderbird as well. Although John and Geoff have been working
on the APIs, the more contributions we get the faster it will go.
The bonus there is that as a result add-ons authors get nice
stable APIs to use and with less code in their add-on.<br>
</p>
<p>Hopefully the new process that John is working on will help to
kick-start this.</p>
<p><br>
</p>
<p>
<blockquote type="cite"><span
style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">Can't bring some hidden UI element on top. In
a corporate environment, I may want my employee to see it
everyday, so that (s)he uses it. If it is hidden in the third
layer, well, .... it's probably not used, or needs extra
time (=money)</span></blockquote>
This sounds like something that should be an enterprise policy,
rather than an add-on. It depends on exactly what it is, but if
this is generally corporate, we should be thinking policies.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c50c5961-7526-d841-c221-d8d8955b0990@optosolar.com">
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">Quickfolders, Smartemplates, connectors to
customer relationship management/ERP/MRP/DMS software:<br>
I see no way how to (ever?) realise that in something similiar
to current<span style="mso-spacerun:yes"> </span>MX. (I am
updating those addons for/with Axel).</span><span
style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de"><br>
I see no way how to realise advanced features without access
to core TB functions (both UI and core handling: mail,
calendar, gloda<span style="mso-spacerun:yes"> </span>etc.).
Have gloda/indexing/search on events and tasks? Maybe by an
addon?</span></p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">Do we willingly say GoodBye to all those
features? It is up to us to define the roadmap. Here in
discussion, and in the next council.</span></p>
</blockquote>
<p>I think we need to be willing to revise some of the expectations
of existing add-ons and maybe adjust some of the
UIs/functionality. We shouldn't compromise them, but we should
look at considering where the best access points are for the UI,
and the best ways of integrating with the back-end. Implementing
an API for every little bit of the UI is not going to be
sustainable, nor is giving access all-areas (I know not everyone
agrees here, that's already been discussed elsewhere so I am not
going to go into it again here) - however I do think we should be
able to get enough common UI interaction points that we can
provide sensible access and UIs for add-ons without too much
difficultly.<br>
</p>
<p>I also think some of those options you are implying we'd have to
drop are not valid. I think it is possible for Thunderbird to add
hooks into gloda and other things. For example, Conversations
currently defines its own gloda providers (which affect the
indexing results). Having looked into it before, I think it is
possible to do in a WebExtension API, the only difficult bit that
I've not looked at yet is how to support removing of the providers
in a sensible fashion (e.g. add-on uninstall).</p>
<p>I've also looked at custom columns - something else which I think
is possible, but needs some work in Thunderbird's core to make it
happen.<br>
</p>
<p>On the "<span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">connectors to customer relationship management"
front, it is possible for WebExtensions to provide <a
moz-do-not-send="true"
href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging">connections
to native software</a>. Whilst it is possibly more
complicated, than what's been provided before, it still is
possible.<br>
</span></p>
<blockquote type="cite"
cite="mid:c50c5961-7526-d841-c221-d8d8955b0990@optosolar.com">
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">4) So, before we continue to discuss the
technology: <br>
</span></p>
<p class="MsoNormal"
style="mso-pagination:none;mso-layout-grid-align:none;
text-autospace:none"><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">(Whether MX, experiments, or something else,
that comes second.)</span> </p>
<p><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">*** do we want to be feature - rich? ***
That is the primary decision. <br>
</span></p>
<p><span style="mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;mso-bidi-font-family:Calibri;mso-ansi-language:
#0007" lang="de">I encourage that we continue the discussion
from that point of view.</span></p>
</blockquote>
<p>I think the answer is yes, and that Thunderbird can do it via
WebExtensions without experiments. I think this needs a bit of
time, and help from the add-on authors to get right.</p>
<p>I think the state of the existing WebExtension APIs is in their
infancy, at the moment and we haven't had the discussions nor
proposals yet about what add-on authors actually need. The UX
parts are likely going to be the tricky ones to get right and
that's something, like everything, that will just need to be
worked through.</p>
<p>Mark<br>
</p>
</body>
</html>