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
  • Apparently, the environment in XPCShell is very limited, and the profile information is not loaded by default. The profile manager is not accessible out-of-the-box, either. I'm thinking of performing the XPCOM tests within Thunderbird using a XULUnit instead, which can also test the user interface
• 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?
• Error codes are in nsError.h
• The password manager is easy to access. I'm going to simply adapt the existing code in the nsMsgIncomingServer.cpp file into JavaScript

Use the SQLite engine that ships with Thunderbird

• It's usable :-)

Running tests in Thunderbird using XULUnit

• Success :-). I now have the XULUnit test structure set up as a Thunderbird extension in its own folder
• With the help of an article on Mozilla's wiki, Thunderbird now has a command line option to run the XULUnit tests, which is -thunderforcetest
• The test framework will be extended to write out the test results to a file so that the tests can be run in pure command line mode
  • Graphical tests can be run from a console, too, with the magic of Xvnc on Linux systems (Linux is my primary dev environment). On Windows, the test window will be visible unless if Mozilla has a special headless way of loading XUL, which might change the dynamics of a test too much in that it's not testing in a realistic environment

Determine a sensible approach for implementing Thunderbird folders

• The nsIMsgFolder folder interface has a lot of properties and methods in it
• Different subclasses can be used for different types of entities, such as documents, cases, accounts, emailmessage, etc
• Filters interoperate with folders, though I think it's optional via a getter in the account
• The class and inheritance structure for the folders should be designed ahead of time and then implemented
• Because JavaScript-based XPCOM classes have to be implemented in one JavaScript file, the Thunderforce folder implementation will likely be a large file
  • Perhaps a simple script can be constructed that concatenates the parts together into one file, especially for subclasses and large functional sections

Determine a sensible approach for implementing a Thunderbird address book

• The address book interfaces can be implemented
• More research is required into address books..
• This might be a nice simple interface to implement either initially or in parallel with the account and folders

Determine a sensible approach for implementing Thunderbird extension details

• Examples include the "about" window and the preferences

Determine a sensible approach for implementing Thunderbird filters

• Filters can probably happen after Dreamforce.. Just getting the account, folders, and address books up and running is a lot of work

Determine a sensible approach for implementing Thunderbird's offline mode

• Post-Dreamforce, and possibly version 2.0