MesQuilla

Mailnews Exchange Support: the Ews Native layer

In the last week, I realized that my Exchange integration project needed another layer in the architecture. Previously, I have discussed a layer that does SOAP calls, and a second layer that extends Mozilla mailnews objects. (Let me call the Mozilla-specific world of mailnews objects MMO “Mozilla mailnews objects” for short). I had thought that I would be able to glue these two layers together through a single method that would send and receive Exchange Web Services (EWS) messages, but that did not work out. The complexity of the data that is returned from EWS is too great to be represented in simple callbacks from the EWS SOAP calls. I also did not want to try to reinterpret that data into MMO terms in the relatively low-level SOAP calls.

So what I have done is to add a new layer of objects, that I call the “Ews Native” layer, that contains data in the format that EWS expects. As a simple example of what I mean by that, folders are identified uniquely in EWS using a very long string called FolderId, while in MMO they are a URI which represents their name and location. The Ews Native layer knows nothing about that URI, it just works with FolderIds.

The Ews Native layer currently consists of the following components:

NativeFolder: contains for example FolderId, ParentFolderId, DisplayName (“Inbox”), FolderClass (“IPF.Note”), and various counts.

NativeMailbox: This would correspond to an “account” in MMO. In addition to account information (name, serverURI, password) it contains a cache that owns the native folder instances.

NativeService: This generates references to native mailbox objects, and owns those objects.

The glue between the Ews native objects and the SOAP layer consists of a method that takes as inputs references to the Ews native objects, and generates specific SOAP calls to operate on those objects. The results of the call are then placed in the Ews Native objects. So, for example, there is a “listSubfolders” call, which uses an EWS FindFolder command to generate a list of FolderIds for the children of a particular folder. The request call then updates the native folder object for the parent, adding (or updating) an internal array of strings containing those ids.

In the unit tests, a call to get the children of the inbox looks like this:

// get children of the inbox
 let request = createSoapRequest(gNativeMailbox);
 response = new EwsSoapResponse();
 request.listSubfolders(response, gInboxFolder, null);
 yield false;

Here gInboxFolder was previously created so that its FolderId was set.

“EwsSoapResponse” is just a js object that implements an interface msqIEwsSoapResponse, that has onStartRequest, onStopRequest methods modelled on nsIRequestObserver. I may eventually implement the full nsIRequest support for my calls, not sure yet.

The request is a C++ object that does the SOAP work, interpreting its results into the Ews native object. The request contains lots of information interesting in debugging (such as the call and response XML), but the actual useful data is stored in the Ews native objects.

In the request object, I have four methods implemented currently: getFolder (which updates folder properties), createFolder, deleteFolder, and listSubfolders. The most complex unit test finds the inbox, creates a subfolder, lists the inbox subfolders to confirm the new folder exists, deletes the new folder, then lists the inbox subfolders again to confirm that it is gone.

Using Outlook Web Services, I can see the results:

The “SubFolder nnnnnn” folders were created by my extension unit tests.

The next step is now to glue the EWS native objects to the EWS-specific MMO objects, and use those to start to show some of the real Exchange Server data in the Thunderbird user interface. This is all part of an attempt to do a complete vertical slice through the overall project, focused on the narrow task of showing EWS objects in the Thunderbird folder pane, so that I can develop and evaluate the overall architecture of the project.