Experiments: Difference between revisions

From Thunderforce
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==
*In progress. To see the current progress, try out the Salesforce.com account signup wizard by creating a new 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

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

Determine a sensible approach for implementing a Thunderbird URL handler for Salesforce

Determine a sensible approach for implementing Thunderbird filters

Determine a sensible approach for implementing Thunderbird folders

Determine a sensible approach for implementing Thunderbird's offline mode

How does Thunderbird's undo/redo manager affect the offline cache?