MesQuilla

Mailnews Exchange Support: First Folder Discovery

I set a goal for myself a few weeks ago to perform a single vertical slice through my Mailnews Exchange Support project, focusing on displaying Microsoft Exchange folders in the Thunderbird folderpane. I have now filled in the missing glue from the architecture in my last post, and have my first display of Exchange Web Services (EWS) objects in the Thunderbird user interface.

The account “rkent@caspia.org” is an Exchange account, and is finding the standard first-level Exchange folders – including some like “Calendar” and “Contacts” that I suppose should be suppressed here, and shown instead in their correct location in Thunderbird’s Calendar and Address Book.

The main issue in getting this phase to work was trying to understand how mailnews startup really works, which was complicated because my usual fountain of all knowledge (David Bienvenu) was on vacation when I needed to make progress. I think that I have figured out that nsIMsgFolder->GetAllSubfoders has been overloaded with the side-effect of initialization, and that happens only at startup, but there are still lots of holes in my understanding of Thunderbird’s IMAP initialization, which is the closest parallel to Exchange within the Mozilla Mailnews Environment (MME). It did become really clear to me though that the IMAP implementation is very much a problem of synchronization betweem two data stores, though that synchronization is fairly invisible in normal modes of using IMAP. All I am doing now is, on expanding the account’s root folder, looking for MME objects representing each of the folders that exist in EWS, creating them if needed. (I am also supposed to be deleting any MME folders that are not in EWS, but you can see from the “rerer” folder that that is not working for some reason.)

This is currently a barely working implementation (like it asserts with a corrupt database the second time I call it). but the point of this was really to better understand the scope of the entire project, and to provide a basis for an initial development of the architecture, followed by a serious evaluation prior to continuing with the bulk of the project.

Having now completed this initial goal, I need to turn for the next few weeks to landing some bugs that sorely need fixing in Thunderbird’s filter code prior to 3.1, as I have been ignoring that for way too long. But before I do, let me record some thoughts on critical issues that I need to face when I return to this.

1. Code division between C++ and JavaScript, internal and external linkage, and comm-central dependencies.

My current implementation is written entirely in C++ as XPCOM objects, but tested using xpcshell unit tests written in JavaScript. The code is split into two extensions.  “webservices” implements the SOAP layer, resides in /mozilla/extensions, and uses external linkage. “exchangews” resides in /mailnews/extensions, consists of both the exchange-specific mailnews objects, as well as the Exchange Native layer, and uses internal linkage. The dependencies are setup so that the SOAP layer is independent, the Exchange Native layer needs the SOAP layer, and the mailnews layer needs the Native layer, and (very weakly) the SOAP layer.

I would like to consider implementing both the SOAP layer and Native layers using external linkage with frozen Mozilla interfaces, so that they could be provided without version dependencies. Then perhaps I could add some generic factories for starter MME objects to the core Thunderbird code in version 3.2, which I could extend using JavaScript to provide the Exchange-specific mailnews objects. That way I could greatly reduce my dependencies on versions in the shipped code.

2. Error logging

The Mozilla framework does not really have a robust centralized error logging and reporting facility, instead there seems to be a multitude of different approaches that don’t cooperate. My current sprinkling of “NS_WARNING” printouts won’t really help in an imagined future where customers encounter failures. I need to reach some decision on how to do this, so that I don’t have to redo the error management when I want to release something.

3. Synchronization

This is very much a synchronization application. I need to consider the overall synchronization strategy, and how much to follow the lead of MME’s existing IMAP implementation.

4. SOAP layer

Partly as a personal education in SOAP, and against the recommendation of several people more experienced than myself, I updated and used the old abandoned Mozilla webservices code as the SOAP layer. Although that is now generally working OK for me, others have suggested that I could accomplish the same thing in an easier, more robust manner using standard XML manipulation routines. I want to attempt to replace one of my SOAP calls using standard XML routines, to see which I prefer, before I implement the 50 or so calls that I will need to glue my Exchange Native layer to the SOAP layer.

5. People

So far, this project has been entirely my own personal effort. But in the future, I envision a small company of 3 – 5 people who provide and support this code, and are able to make a living doing so. The hope is that I could be independent of, but cooperative with, the main Mozilla Messaging team that supports Thunderbird. (That is, I hope to answer “no” to my question “Do MEALS need a fork?“) At what point should I be adding people to this team? A one-person development team can be quite efficient if it can get the job done, as you eliminate all of the effort associated with maintaining relationships and communication. I think there is a reasonable (50/50) chance that I can get this project done on my own by the end of 2010 and/or in sync with Thunderbird 3.2, as is my current goal. I’ll need to firm this up by the end of June. But I would be open now to beginning to partner with one of the experienced volunteer mailnews developers (you know who you are) who has similar interests.