Experiments

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, which is build into Thunderbird, throws NS_ERROR_NOT_IMPLEMENTED for its defaultLocalPath setter
• When gdb is used to debug Thunderbird, the Thunderbird user interface takes a long time to start up and runs slowly. Venkman and the error console, thankfully, both work when gdb is debugging Thunderbird (with Venkman, it's a debugger within a debugger)
• The about:config display extension does not appear to work in my debug build of Thunderbird (line 105 of chrome://about_about/content/mrtech-common.js says "browserWindow has no properties")
• Returning the wrong object type in JavaScript code produces a vague NS_ERROR_FAILURE without further details. Be sure that return types are always correct
• Watch out for properties that have the [noscript] annotation. These are apparently not marked as such on XULPlanet.com, but can be seen in the interface's IDL file
• JavaScript apparently cannot extend a native C++ class. This means that Thunderforce cannot reuse the functionality built into the nsMsgIncomingServer base class implementation of nsIMsgIncomingServer unless if that part is in a native library. Having a native library reduces portability, but not having a native library increases the amount of code required in Thunderforce to re-implement the relevant parts of nsMsgIncomingServer in JavaScript as well as increasing the implementation time
  • This is an architectural trade-off
  • Re-implementing the necessary parts of nsMsgIncomingServer in JavaScript actually isn't that bad and, in all functions thus far, the JavaScript code is a fraction of the lines of code that the C++ versions need, though the execution time is probably about the same or slower than C++
• While thinking about the architectural trade-off above, I realized that any of the above approaches will require at least automated nightly testing with the latest Thunderbird code to ensure that changes to Thunderbird don't break Thunderforce for its use
  • The automated update mechanism in Thunderbird 2.0 and above can make changes to Thunderforce as painless as possible to its users, and the automated nightly testing can help the Thunderforce dev team greatly reduce the risk of new Thunderbird patch and full releases breaking Thunderforce
  • If a native library is used for the account code, it's possible that interface changes to nsIMsgIncomingServer can cause Thunderbird to crash. With JavaScript, Thunderbird shouldn't crash but, instead, Thunderforce will fail to operate properly
    • A detection mechanism for this to gracefully fail Thunderforce might be easier to implement when everything is in JavaScript. Perhaps this can be accomplished by automatically running a small set of unit tests whenever the version of Thunderbird changes
• XPCShell can be a good way to run sanity and unit tests on code before trying it out in Thunderbird, though I haven't yet figured out how to get it to use my Thunderforce testing profile in Thunderbird
• I need to make sure that "throw Components.Exception(message, Components.results.NS_ERROR_FAILURE);" works as a way to throw an exception with a detail string (TODO)
• Is there a way to include one JavaScript file into another in XPCOM components? I really hope there is..
  • I defined various quality assurance functions such as assert(), assertNotNull(), and assertEquals(), but it would be nice to have this defined once instead of in each XPCOM object. Perhaps these QA functions should be in their own XPCOM object?

Determine a sensible approach for implementing Thunderbird extension details

• Examples include the "about" window and the preferences