JSAccount, ExQuilla, and TB 60
On 3/6/2018 11:46 AM, Jörg Knobloch wrote:
P.S.2: Thanks to Kent for interrupting his retirement to take care of
JSAccount URLs. Kent, please try ExQuilla now!
TL;DR version is that ExQuilla will work eventually in TB 60, but not
likely after that, and is transitioning to a non-paid addon for now.
Let me give a more extended comment on this, which might be of interest
to maildev subscribers. (For those who don't know, ExQuilla is a
Thunderbird addon that provides access to mail and contact accounts
using Exchange Web Services. This relies on a core Thunderbird
capability called JsAccount that was implemented in TB 52).
JsAccount
On JsAccount, originally I had hoped that it could serve as a basis for
other account type implementations within Thunderbird using JavaScript,
such as JMAP. Unfortunately after making ExQuilla work with TB 52, I
have serious doubts about the viability of that. Three big obstacles:
-
Rapid underlying Gecko changes. JsAccount relies on XPCOM and the
JS hooks (is that XPCONNECT?) and core Gecko seems to be determined to
rip that out and reduce its functionality. The recent URI changes are a
good example of that. We added core hooks in JsAccount to keep that
working, but it is not clear that it will always be possible to do that
with a technology like JsAccount that is a fairly sophisticated user of
XPCOM and XPCONNECT. -
Conceptually, the JsAccount objects are hard to get correct. When
you create JsAccount-derived objects, it is quite tricky to know what
you really have. So if I create, say, a JsAccount-derived JS object
(like a folder instance for example), it could be any of the following:
- an XPCONNECT-wrapped reference to the underlying nsJaMsgFolder.cpp
base class object (which is actually an XPCONNECT-wrapped Super
object of JaCppMsgFolderDelegator) which will always use the base
class methods. - an XPCONNECT-wrapped JaCppMsgFolderDelegator which will delegate to
JS overrides if available. - an XPCONNECT-wrapped reference to the underlying JS implementation
of a folder object. - an XPCONNECT-wrapped reference to the account-type specific
JS-implemented extension of a class (analogous to, say,
nsIMsgImapMailFolder.idl, with the difference being this has to be
obtained using nsIInterfaceRequestor and not with a simple QI to the
base object). - a jsval reference to the account-specific JS implementation.
You can get references using QI from an existing object, creating a new
XPCOM object, creating a new JS object, implicitly using (object
instanceof ...), getting the wrappedJSObject, and using
nsIInterfaceRequestor. It is really tricky to keep all of these clear
and correct in your code, and they have subtle differences in behavior
and capabilities.
- There are still too many places in the underlying mailnews and
mozilla code where there are lists of supported account types, and the
equivalent of (if imap then ... else if pop then ...) and you cannot
extend those directly. In theory you could fix those, but there is no
firm commitment to do that, so it is a game of whack-a-mole to find them
all. What you end up doing is a lot of fragile workarounds to fix these
types of issues.
So I concluded a year ago that JsAccount is not likely to be a viable
path forward for either new account types, or for JS implementations of
existing account types. Interesting experiment, and it can be made to
work, but just too complex and fragile.
ExQuilla use licences
ExQuilla was monetized using a paid annual subscription model. That
means that if I sold a subscription today, then I was sort of
guaranteeing that it would work for another year. Looking to the future,
and the rapid changes in Gecko, I have very serious doubts whether the
core JsAccount technology that ExQuilla relies on will be viable in the
next major version of Thunderbird after TB 60, which is presumably TB 67
that would release about a year from now. So I did not feel that I could
sell a license that looked forward past March 2019. For that reason,
I've stopped selling licenses, and am instead automatically providing
updated six-month licenses. ExQuilla for TB 60, when it releases, will
not require a license. Essentially, for now, ExQuilla is no longer a
paid application. I have ExQuilla mostly working for Thunderbird 60
though, so it should be good for another year once I release that to AMO.
ExQuilla software license
I'm torn on the issue of the ExQuilla software license. Now, it is a
nondescript proprietary license. The bias of subscribers to this list is
likely to be "just make it an open source license like MPL."
But ExQuilla is an extremely complex extension. IMHO it is unlikely that
such an extension could be supported in the long-term by for-free
volunteers. The source code is currently de-facto open since it is
readily viewable in the published AMO extension, but the repo is
currently a private Bitbucket repo.
Generally I am willing to do whatever is in the best long-term interest
of Thunderbird users who want access to Exchange Web Services-based
accounts. If there was a serious interest by Thunderbird core in merging
ExQuilla into the core code, then I would be willing to MPL the code and
let that happen. But if that does not happen (and my guess is there is
not sufficient support for that to happen), then I want to preserve the
possibility for someone in the future to take over ExQuilla as a paid
extension.
So for now, my intention soon is to move ExQuilla to a public Github
repo, but leave the license proprietary, and ask anyone who wants to
contribute to assign their rights. I believe this has the best chance of
leaving the door open for someone in the future to attempt to take over
ExQuilla as an income-generating project, which IMHO is in the best
interest of the current and future users of ExQuilla.
:rkent