[Maildev] JSAccount, ExQuilla, and TB 60

R Kent James kent at caspia.com
Wed Mar 7 12:49:09 EST 2018


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:

1)    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.

2)    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.

3)    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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/attachments/20180307/73e94957/attachment.html>


More information about the Maildev mailing list