What is the future of JS Account?
Hi all,
JS Account was implemented to support Kent's ExQuilla add-on and potentially other protocols like JMAP.
However, Kent wrote in the message quoted below:
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.
JS Account is deteriorating. Still working at TB 60, broken at TB 61 with one test failing (https://bugzilla.mozilla.org/show_bug.cgi?id=1447492). I've just had to switch off another test (https://bugzilla.mozilla.org/show_bug.cgi?id=1475166).
So what are we going to do with an unowned and deteriorating module that is apparently not fit to be used for further account types? Remove it?
Jörg.
On 07/03/2018 18:49, R Kent James wrote:
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
If it doesn't cause too much maintenance burden, keep it around as take
another look after ESR 68?
It's basically affecting ExQuilla only right? I don't know of any other
account types planned to use it. If there are, maybe someone
implementing such an account type wants to champion JsAccount and make
sure it's working.
-Magnus
On 12-07-2018 12:46, Jörg Knobloch wrote:
Hi all,
JS Account was implemented to support Kent's ExQuilla add-on and
potentially other protocols like JMAP.
However, Kent wrote in the message quoted below:
/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./
JS Account is deteriorating. Still working at TB 60, broken at TB 61
with one test failing
(https://bugzilla.mozilla.org/show_bug.cgi?id=1447492). I've just had
to switch off another test
(https://bugzilla.mozilla.org/show_bug.cgi?id=1475166).
So what are we going to do with an unowned and deteriorating module
that is apparently not fit to be used for further account types?
Remove it?
Jörg.
On 07/03/2018 18:49, R Kent James wrote:
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
Hello Jörg,
I was planning to maybe port JS accounts to WebExtensions, as part of TB 67.
Ben
Am 12. Juli 2018 11:46:07 MESZ schrieb "Jörg Knobloch" jorgk@jorgk.com:
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
--
Sent from my phone. Please excuse the brevity.