New Account Types directions - should SkinkGlue be core?
asutherland at asutherland.org
Fri Apr 29 17:10:26 UTC 2011
On 04/26/2011 01:16 PM, Kent James wrote:
> So I am asking the question, is there any interest in make SkinkGlue
> part of the core Thunderbird distribution?
I would propose we do the following:
1) Review and land the skink glue stuff (possibly after bienvenu lands
pluggable storage?), BUT:
2) Make its building conditional on a --enable-skink-glue or equivalent
3) Only --enable-skink-glue on the "Thunderbird Experimental" stream
builders (and for developers, somehow). Not beta, not release.
4) Gate its enabling on beta (and eventually stable) on there being a
JS-based account type that we want to broadly distribute either as part
of the product or as an endorsed extension.
The rationale is this:
a) You are right, everyone hates binary add-ons and in the new train
model what was previously a highly unpleasant experience for binary
add-ons is now a nightmare. Accordingly, it would be a catch-22 for
SkinkGlue to prove its worth given that it would be hard for people to
use it at all.
b) SkinkGlue is currently the only viable JS-based new account model and
this is a nice thing for people to be able to experiment with, but it
needs more testing with crash-stats feedback before wide-scale
distribution. The other alternatives for new account types do not
appear likely to be competitive anytime soon. Joshua's solution is
technically interesting but also terrifying, and the gloda solution
(which would also require UI layer work) is not currently being worked.
c) TweeQuilla is an excellent open-source example use-case. Kudos!
d) As a long-term active contributor to Thunderbird it seems unlikely
you'd land it and disappear leaving us without anyone willing to hack on
it. Given that SkinkGlue does not seem particularly technically risky,
just more of a maintenance thing, as long as you are willing to be
module owner and keep it up-to-date in the form of collaborating on
patches with any changes being made to the C++ back-end, it should not
significantly increase code burden for the tree.
The important caveat is that this is not my call, especially as I would
not be dealing with any of the additional code complexity, etc.
More information about the tb-planning