New Account Types directions - should SkinkGlue be core?

Kent James kent at caspia.com
Fri Apr 29 19:33:38 UTC 2011


On 4/29/2011 11:50 AM, Jim wrote:
> If we decided to make any significant
> changes to, say, IMAP, would it make sense to implement parts of it in
> terms of SkinkGlue?
I doubt it. What SkinkGLue mostly does is create XPCOM objects that 
start from the same base C++ code that IMAP, POP3, and NEWS C++ objects 
use as their parents. So javascript objects can take advantage of the 
same default implementations that the C++ objects do. Improvements in 
SkinkGlue would have the same impact on changes in IMAP that, say, 
improvements in POP3 do. Some, but not much. Whenever possible, it is 
better if the changes are done in the base objects (like 
nsMsgDBFolder.cpp) so that all of the account types (IMAP, POP3, News, 
and SKinkGlue) get the changes.

What I would love to see done though would be to revise the core 
interfaces like nsIMsgDBHdr and nsIMsgFolder to have a core .idl with a 
minimum set of common functions, and use extensions of that for methods 
needed only by a subset of  account types. That would require a lot of 
QueryInterface calls as the cost, but the benefit would be that it would 
be easier to create an account type from scratch, ultimately in js, 
without having to implement a lot of rarely used functions.



More information about the tb-planning mailing list