Experiments: Difference between revisions
Jump to navigation
Jump to search
Line 6: | Line 6: | ||
==Determine a sensible approach for implementing a Thunderbird account== | ==Determine a sensible approach for implementing a Thunderbird account== | ||
* | *[http://www.xulplanet.com/ XULPlanet.com] is a great source of documentation for the Mozilla platform's interfaces | ||
*The IDL files in the Mozilla source code do not indicate interface inheritance. Apparently, all the inheritance takes place in the interface implementations | |||
*Setting a preference char value on a preference branch apparently doesn't work when no values existed in that preference branch (or maybe that's always the case? I'm not sure. This is when I was using nsIPrefService instead of nsIPref to get the branch, so perhaps that was the reason?). Setting that preference using nsIPref instead of nsIPrefBranch appears to work fabulously | |||
*The setters for nsIMsgProtocolInfo.defaultLocalPath and nsIMsgIncomingServer.defaultLocalPath are only called by the Thunderbird profile migration code, and new account types don't (yet) need to implement it; it's called on a case-by-case basis by migration for each specific incoming server type that migration knows about, which does not include Thunderforce. To make this an even safer bet, nsRssService throws NS_ERROR_NOT_IMPLEMENTED for its defaultLocalPath setter | |||
==Determine a sensible approach for implementing a Thunderbird address book== | ==Determine a sensible approach for implementing a Thunderbird address book== |
Revision as of 02:59, 8 July 2007
This page lists the experiments that resulted from the notional architecture review.
Using the Salesforce.com AJAX toolkit in a Thunderbird extension
- This works perfectly and exists in the current Subversion source code
- For production, the AJAX toolkit will exist within an XPCOM interface implementation consistent with the Salesforce.com data layer in the architecture
Determine a sensible approach for implementing a Thunderbird account
- XULPlanet.com is a great source of documentation for the Mozilla platform's interfaces
- The IDL files in the Mozilla source code do not indicate interface inheritance. Apparently, all the inheritance takes place in the interface implementations
- Setting a preference char value on a preference branch apparently doesn't work when no values existed in that preference branch (or maybe that's always the case? I'm not sure. This is when I was using nsIPrefService instead of nsIPref to get the branch, so perhaps that was the reason?). Setting that preference using nsIPref instead of nsIPrefBranch appears to work fabulously
- The setters for nsIMsgProtocolInfo.defaultLocalPath and nsIMsgIncomingServer.defaultLocalPath are only called by the Thunderbird profile migration code, and new account types don't (yet) need to implement it; it's called on a case-by-case basis by migration for each specific incoming server type that migration knows about, which does not include Thunderforce. To make this an even safer bet, nsRssService throws NS_ERROR_NOT_IMPLEMENTED for its defaultLocalPath setter
Determine a sensible approach for implementing a Thunderbird address book
Determine a sensible approach for implementing Thunderbird extension details
- Examples include the "about" window and the preferences