<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I just like to add, that I do have a few bugs on my list, also
some of those mentioned by Klaus, but currently my focus is on
supporting add-on developers and getting the API proposal process
outlined and not yet on fixing bugs. I need to prioritize that at
the moment.</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 27.09.2020 11:09, Mark Banner wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fd7abfff-ad6f-2aeb-23ad-50aef4d8961d@mozilla.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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> </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><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
</body>
</html>