New Account Types directions - should SkinkGlue be core?
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
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
interfaces, rather than the C++ implementation as is currently done.
have this msqIOverride layer that you used, rather than just use the
interface is to manage the mismatch in object inheritance methods
of core mailnews components, that would be implemented initially using
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
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
been able to come up with myself.
Perhaps it would be helpful if I would describe SkinkGlue as really
consisting of 2 pieces.
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
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
More information about the tb-planning