New Account Types directions - should SkinkGlue be core?

Kent James kent at caspia.com
Mon May 2 16:12:38 UTC 2011


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 
http://hg.mozilla.org/users/kent_caspia.com/skinkglue/file/fd799127dbb0/public/msqIOverride.idl)  
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




More information about the tb-planning mailing list