<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
This post is requesting that the Thunderbird developer community
give feedback on the SkinkGlue approach to new account types in
Thunderbird.<br>
<br>
In dmose's existing <a
href="https://wiki.mozilla.org/User:Dmose/Tb_Product_Notes">Thunderbird
product direction</a>, one of seven product priorities is:<br>
<br>
''Thunderbird will focus on conversations that occur over mainstream
and emerging communication channels. These include email, web
forums, social networks, and microblogging services."<br>
<br>
I interpret that as a priority that Thunderbird should be able to
integrate new account types beyond RSS, IMAP, and POP3 using
extensions.<br>
<br>
Although jcranmer did a <a
href="http://quetzalcoatal.blogspot.com/">series of blog postings</a>
on trying to add some new communication channels to Thunderbird
using javascript, so far this has not resulted in a workable
approach. In December of 2010 <a
href="http://mesquilla.com/category/skinkglue/">I investigated an
alternative approach</a> that created a JavaScript-overridable
version of key mailnews objects, which I call <a
href="http://mesquilla.com/extensions/skinkglue/">SkinkGlue</a>.
(For the <a
href="https://addons.mozilla.org/en-US/thunderbird/addon/new-account-types/">AMO
entry for SkinkGlue</a>, I call it by the friendlier but boring
name of "New Account Types"). I also created a demonstration
extension that uses SkinkGlue called <a
href="http://mesquilla.com/extensions/tweequilla/">TweeQuilla</a>,
showing what it takes to implement Twitter into Thunderbird using
JavaScript plus SkinkGlue. Source code for <a
href="http://hg.mozilla.org/users/kent_caspia.com/skinkglue/">SkinkGlue</a>
and <a
href="http://hg.mozilla.org/users/kent_caspia.com/tweequilla/">TweeQuilla</a>
are available publicly, and released with a standard Mozilla
tri-license. (Unfortunately the AMO versions of these got caught in
AMO review queues and issues. I need to do a new blog posting with
self-hosted versions of these for testing.)<br>
<br>
From my perspective, the developer reception to the SkinkGlue-based
approach has been lukewarm. I've heard complaints that it is based
on the mork nsIMsgDatabase implementations rather than gloda, and
that the overridable API that is key to its working seems like a
kludge. I haven't really heard any encouraging statements.<br>
<br>
After having used the SkinkGlue API to develop a couple of new
account types now (Twitter and Exchange Web Services), my experience
is that overriding the base C++ mailnews objects with JavaScript
components is not any more difficult than the equivalent overriding
in a C++ XPCOM object. As far as I can tell, the approach works just
fine. The approach of using a base C++ object that take
responsibility for calling any JavaScript overrides also avoids
subtle issues like <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=606465">bug
606465</a> which occur in email classes as well.<br>
<br>
It will be difficult for SkinkGlue to be effective for anyone other
than myself as long as it remains a binary addon, which are
discouraged in AMO and difficult to maintain. If this is the
near-term approach that Thunderbird plans to take to new account
types, it really should be shipped with the core product so that
extensions do not need to deal with a separate binary extension. The
Windows version is a 201KB dll file (if incorporated into libxul it
would probably be smaller).<br>
<br>
So I am asking the question, is there any interest in make SkinkGlue
part of the core Thunderbird distribution?<br>
<br>
I'm looking for more here than the usual "If you put a lot of work
into making this viable, then we might consider adding it to core".
If new account types are a strategic priority, and SkinkGlue is an
important supported approach to that, then I would expect to see
other people who are willing to try using it to add a simple new
account type. (It would also be great for someone with Mac
experience to review the C++ code to see what it takes to be
compilable there). I'd also like to see some sort of higher level
decision, more than just an r+ on a bug, that shows some commitments
to this direction. Without that, I will probably just to keep this
in my own little private <a href="http://mesquilla.com">MesQuilla</a>
world.<br>
<br>
So what is the interest in this?<br>
<br>
rkent<br>
<br>
<br>
</body>
</html>