New Account Types directions - should SkinkGlue be core?
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
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