New Account Types directions - should SkinkGlue be core?

Jonathan Protzenko jonathan.protzenko at
Thu May 12 14:46:53 UTC 2011


As part of the "Thunderbird developer community", here's my feedback on
your proposal. I tend to see this in terms of the expected outcome,
which is integrating Exchange services and Twitter into Thunderbird — I
love both these ideas. Plus, these are directions that have great
potential. With Thunderbird now becoming the default in Ubuntu, I think
we should put a lot of effort into the Exchange compatibility, which
Evolution has.

There's a little bit of vacancy right now in terms of management, as the
team is reintegrating Mozilla, which probably doesn't help you get
strong commitments towards merging this into the main product. But I do
think this a great proposal, albeit slightly complicated. The way I see
this is:
- there is a lot of machinery involved, and this will probably make
adding new account types really hard unless the person is familiar with
writing Thunderbird code,
- however, doing a full rewrite of the interfaces is not applicable, as
we're far from having the required workforce for this.

Assuming (and this all depends on the orientation that the future
product manager for Thunderbird will choose) we continue into this
direction, I think we should merge SkinkGlue and have you commit to
providing both Exchange support and Twitter support for Thunderbird, as
"official extensions". When we feel they're ready, we might even /
should integrate them.

If I understood well, this also provides a nice abstraction layer for
implementing new address book types. Could you please explain how does
that relate to mconley's work on de-RDFing address book? Is your skink
glue compatibility layer still required? Can we get rid of it? I'm
thinking about broader commitment to rewriting the address which I feel,
unlike rewriting the other interfaces that you fix with skinkglue, is
within reach.

Thanks for your hard work and your commitment,


On 05/02/2011 06:12 PM, Kent James wrote:
> On 5/2/2011 7:11 AM, Ben Bucksch wrote:
>> On 26.04.2011 22:16, Kent James wrote:
>>> So I am asking the question, is there any interest in make SkinkGlue
>>> part of the core Thunderbird distribution?
>> How about this:
>> 1. We define how the API / IDL for a JS-based account implementation
>> should look like, independent of any implementation
>> 2. You implement that API using "SkinkGlue"
> This does not really make sense short of a wholesale rewrite of the
> core mailnews interfaces, which I am not prepared to do.
> There is very little "API/IDL" that is unique to SkinkGlue. It
> primarily adds a mechanism for JavaScript-based XPCOM components to
> inherit from a C++ base, including mechanisms to override the standard
> C++ implementations, and call base methods. (See
> Otherwise, it just provides components that implement base mailnews
> interfaces like nsIMsgFolder. So when you ask to define the API,
> really is it just the standard existing mailnews API. It does not make
> sense to define a separate API for new account types, without also
> simultaneously changing the API that the C++ components use.
>> 3. "SkinkGlue is included in Thunderbird
>> 4. Once we have a better approach, that replaces SkinkGlue, but the
>> JS account implementations don't notice the change.
> I don't see any reason why the three main methods of msqIOverride.idl
> could not work with a javascript-based implementation of the core
> interfaces, rather than the C++ implementation as is currently done.
> However, if you had a 100% javascript solution, it would be annoying
> to have this msqIOverride layer that you used, rather than just use
> the core object management methods in JavaScript. The main point of
> that interface is to manage the mismatch in object inheritance methods
> between JavaScript and C++.
> It might sound like a good idea to have a base JavaScript
> implementation of core mailnews components, that would be implemented
> initially using SkinkGlue but eventually by a JavaScript-replacement.
> Unfortunately this does not work. If there is a C++ component anywhere
> in the inheritance chain of an XPCOM component, then that C++
> component is what is passed to C++ callers. So overrides that you try
> to do of the XPCOM component using JavaScript mechanisms are not seen
> by the C++ objects, so the overrides fail. That is one of the main
> purposes of the msqIOverride mechanism. It might be possible to
> automate some aspects of the use of msqIOverride (such as
> automatically detecting the existence of JavaScript overrides of base
> classes) but that is not something I have been able to come up with
> myself.
> Perhaps it would be helpful if I would describe SkinkGlue as really
> consisting of 2 pieces.
> One piece is the msqIOverride mechanism to allow JavaScript components
> to inherit from C++ components, along with declaring XPCOM components
> that can be instantiated with the standard mailnews base classes
> (nsMsgDBFolder, nsMsgIncomingServer, etc.)
> A second piece consists of a particular set of overrides of the
> standard C++ base classes, that makes it easier to create a new
> account type. For example, various decisions about the management of
> the summary database and the mapping of an nsIMsgFolder to the file
> system are normally delegated to the account type-specific functions
> like nsImapMailFolder, but the SkinkGlue equivalent msqSgMailFolder
> make its own set of decisions of how to do this. Also, various
> problems the make it difficult for JavaScript-based components to use
> the core implementations and interfaces are solved with the SkinkGlue
> overrides. Many of these could be eliminated if it was a priority to
> make the core interfaces and components reliably scriptable.
>> I don't think having this in Thunderbird source tree, but not enabled
>> in main TB builds, is very useful.
> I agree with this. It creates work for me without really providing any
> benefit.
> rkent
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list