You’ll need to install my addon JunQuilla to enable one critical piece of user interface. JunQuilla supports a folder property that lets you selectively enable or disable junk processing for a tree of folders. So after you’ve installed JunQuilla, enable processing of junk for a newsgroup:

This will run future posts sent to the newsgroup m.d.a.thunderbird through the bayes junk filter in Thunderbird. After this is enabled, some of the junk management controls on the folder should be enabled. Try “Run Junk Controls on Folder” to process existing posts for junk.

But nothing will appear to happen when you do, because there is no functionality to delete or hide the junk messages for newsgroups built in. Still, you can see the results using JunQuilla’s “junk percent” and “junk status +” columns:

The next step is to remove those junk messages from your view. The easiest thing to do is to create a virtual folder that shows the messages in the newsgroup without the junk messages. This is where the user interface fights against you. But you can trick it in the following manner.

Create a virtual folder on a message folder with search criteria “Junk Percent < 80″. Save the folder as a subfolder of a local mail folder. Now open the virtual folder and change the folders that it scans, removing the original folder and replacing it with the newsgroup folder:

Now the spam posts are hidden from this virtual folder:

You may need to specifically train the junk filter using a few junk and good messages in news. But the good news is that newsgroup spammers are not really optimizing against bayes filters, so it seems to be a lot easier to detect newsgroup spam than mail spam.

With all respect for the people working at Mozilla/Thunderbird and fully understand the limitation they are faced with, I would like to see a more detailed mission statement for the products (TB/LG) and the future of it. Only expressing TB is for individual users, SOHO and not for the Enterprise is a very vague  statement

I was going to respond to that in the thread, but I got wordy so I posted this blog entry instead.

At the recently completed Mozilla Summit, variations of this request were made by many people that are close to the Thunderbird project (including myself). But after listening to several days of Firefox people extolling the virtues of moving everything to the browser, and being “more like the web”, I have a new appreciation of how difficult the development of a vision statement is for the Thunderbird team.

The standard game plan that Mozilla projects are expected to follow is to develop an application with a significantly high market share so that they can use their market influence to fight for the rights of individual users. Mozilla is a fascinating organization as a hybrid commercial/public interest organization, and they take their values quite seriously.

Unfortunately Thunderbird, which is the only real product that MoMo currently has, hovers around 6 million users, which is much lower than the number they believe are necessary to have the influence they would like (I have heard 100 million users as a goal). Nobody currently has a concrete plan to develop a product with 100 million users. So the current strategy (as I see it) is to try a series of experiments to try to develop some concepts that might be used to specify the 100 million user product. I can’t resist naming things (my wife calls me “an Adam”), so let’s call this future product by the code name “Gigabird”.

One such experiment is Raindrop. Other experiments are going on in extensions to Thunderbird, which seem to be focusing on changes to the user interface. Right now, that is where the vast majority of the developer resources are focused at MoMo.

So if your real strategic mission is to develop Gigabird, what do you do with your legacy product Thunderbird? The big problem is that the “ordinary users” that are the primary focus of Firefox (and by implication also MoMo) are migrating away from email for many forms of messaging to other media – Twitter, Facebook, text messages, web forums, blog comments, etc. The hardcore users of email (who are likely to continue to use a desktop client) are sitting in office cubicles, yet going after these “enterprise” users is counter-cultural for Mozilla.

So what are the strategic choices available to MoMo?

the HailMary

The goal here is to try to come up with one or more really clever innovations that will form the basis of Gigabird. This is, after all, the way that some of the new messaging formats have occurred, with Twitter as the poster child. Using these innovations as a base, the basic plan for Gigabird will be formulated at some point in the future. This is the current MoMo strategy, at least as I see it. Given the existing Mozilla culture, I would probably do this as well. (Warning: should this strategy every become publicly revealed, the director will disavow any knowledge of these actions.)

the AboutFace

Here you notice that the values-driven direction that you felt so passionate about is actually not going to get you anywhere, so you make a major readjustment in values to allow you to pragmatically accept a new direction. Such moves have been done by Mozilla in the past, and are part of the standard corporate Myth propagated by Mitchell Baker (the story about how in the early days they were adamant about never shipping a binary). The application to MoMo could be to accept that what they have is an email product, and their future users are going to be sitting in cubicles. Users in cubicles should have rights too, so there could be a valid Mozilla Foundation purpose in fighting for the rights of these “enterprise users” and let Thunderbird develop into an enterprise product.

the SlowPlod

This is the direction that existing Thunderbird users are hoping for. The ultimate goal is to slowly improve Thunderbird until it is undeniably the best email client around. You fix any important bugs.  You support all of the hot new messaging concepts. You spiff up the user interface, incrementally adding new features that provide small improvements to usability. You keep your power uses happy with lots of extensions for specialized purposes. It’s pretty clear that dmose does not believe that he has sufficient resources to pursue this strategy, nor is he likely to have them in the foreseeable future. The Thunderbird code base is also really hard to adapt to these new media (witness the struggles that I have had or jcranmer’s blog ). I think that the MoMo team wishes us well, but believes that the future lies elsewhere.

the VacuumTube

Just because you can’t change the direction of humanity does not mean that you have nothing. Vacuum tubes are long gone – yet the guitar player at my church proudly uses his fancy amp with glowing tubes showing through plexiglass. The company that bought one of my previous businesses had also previously purchased a manufacturer of vacuum tubes, which had morphed into specialized purposes like lamps for spectroscopy, and nuclear-warfare-resistant cathode ray tubes. Email clients will be with us forever, and in the hands of people who love them could have a useful future in various niches.

My Prediction

MoMo will pursue the HailMary until they have enough ideas to formulate a real plan. At that point, they will want to devote all of their resources to Gigabird, and be looking for an honorable way to retreat from Thunderbird – which will be a variation of the VacuumTube. The likely retreat will probably be some sort of future custodianship by a conglomeration of companies that provide a freemium strategy. So if there was a basic, free Thunderbird product that could be enhanced with addons with commercial value (like my Exchange Web Services product, or Postbox as a Thunderbird addon), then MoMo could pursue their vision without abandoning their Thunderbird users, and let companies like MesQuilla and Postbox support Thunderbird.

Perhaps it would be interesting to show how I hooked into the sending function in the user interface. I asked the usual suspects, and it was not clear to anyone that it could be done without adding backend hooks – which I would like to avoid as much as possible to increase my chances of getting some initial alphas of this released to work with existing TB 3.1 users.

It turned out to be fairly straight forward. In MsgComposeCommands.js there is an observer notification that occurs, called “mail:composeOnSend”. This occurs right before the UI is ready to call SendMsg on the nsIMsgCompose object gMsgCompose. So what I needed to do was to intercept that call, and implement my own version of SendMsg rather than the SMTP/Rfc822-focused standard C++ code. To do that, I create a new object when I receive the notification with the old object as its prototype, then include a custom SendMsg that only applies if the sending account is an Exchange server. The overlay code ends up looking like this (greatly simplified):

function observe(subject, topic, data) {
 // wrap the gMsgCompose object so that we can detect attempts to
 //  send using ews.
 let newCompose = new ewsCompose(gMsgCompose);
 gMsgCompose = newCompose;
}

// ewsCompose provides a wrapper around the compose object, so that we
//  can override functions.
function ewsCompose(oldCompose) {
 this.oldCompose = oldCompose;
 this.SendMsg = function ewsSendMsg
     (msgType, identity, currentAccountKey, msgWindow, progress) {
   if (incomingServer instanceof Ci.msqIEwsIncomingServer) {
     // sending using Exchange Web Services (details not shown)
     // ...
     ewsCompose.sendMsg();
     return;
   }
   else
     return this.oldCompose.SendMsg
       (msgType, identity, currentAccountKey, msgWindow, progress);
 }
 this.__proto__ = oldCompose;
}

This seems to work just fine. It was a little tricky getting the compose code to believe that I had actually sent the message, so it could quit complaining of an unsent message. What I ended up doing in my “sending succeeded” callback is to add a few shutdown calls:

let ewsEventListener = {
  // msqIEwsEventListener implementation
  onEvent: function onEvent(aItem, aEvent, aData, aResult) {
    if (aEvent == 'StopRequest') {
      // ewsProgress was saved from the "progress" variable
      //   in nsMsgComposeCommands.js
      if (ewsProgress)
        ewsProgress.closeProgressDialog(aResult == Cr.NS_OK ? false : true);
      stateListener.ComposeProcessDone(aResult);
      MsgComposeCloseWindow(true);
    }
  }
}

With the ability now to send and receive messages, I’ve completed a single vertical pass through all of the key functionality. There are many, many details that I have passed over in the process. But it’s time to start thinking about what I would need to make work to get a usable alpha release of this, perhaps in about six weeks.

EWS messages do not come from the server in RFC-822 format, so it seems like a pity to store them that way, though that is the common method used in the rest of the mailnews codebase. Instead, I decided to implement a local storage scheme based on SQLite and Mozilla’s Storage interface. Andrew Sutherland has done a lot of great work setting up an environment similar to this for the gloda database, so there are lots of good examples to pull from. Also, because the datamodel for EWS includes not only messages but also Calendar and Contact items, I can have a common database infrastucture that I can leverage over those other pieces once I get it working for the messaging part.

I’ve now replaced my previous in-memory datastore for message metadata with an SQLite version. This is equivalent to the datastore module in gloda, and the data it is storing is like the RFC-822 headers. I still have to do the storage for the body, and also hook this up with folder change state so that the code knows that it has data it can trust.

As I have done this, I’ve had a new set of insights into the relationship of the various objects in the Mozilla mailnews world (which I sometimes call Skink). Previously, I had sort of expected that the natural progression of gloda would be to slowly displace the role of the message summary database, nsIMsgDBHdr.  But now I see that a more natural progression would be for SQLite to be used as a replacement for the local mailstore (currently mbox, with maildir support moving forward as well.) Really the main issue is the async nature of the SQLite calls, which sort of precludes its easy use as a replacement for nsIMsgDBHdr. But the datastores are typically accessed async anyway. If the message metadata in the message stores was stored primarily in SQLite format, as I will be doing, then it would be much easier to hookup an SQLite-based global search facility to all of these databases. Yes that is what gloda does now, but it has to go through all of the work to maintain a separate version of everything. Why have three copies of everything (Mork, MBox, and Gloda) when you could only have two (Mork and Gloda)?

As another insight, while looking through the gloda code I noticed that a JSON object was being saved to store some of the items. I though that was a good idea at first – but then I tried to write a simple serializer to convert from my internal native format to JSON objects, and saw that it was not going to be an easy project. But then I remembered that SOAP is really just a mechanism to serialize typed objects, and I already have a SOAP encoder and decoder! So instead of using JSON, I use objects serialized with my SOAP XML encoder to store unindexed items in my SQLite store. So a message (sans body) ends up looking like this as a TEXT item in SQLite:

<Message xmlns="http://schemas.microsoft.com/exchange/services/2006/types">
 <Subject>Postini First Junk Email Safely Quarantined</Subject>
 <DateTimeReceived>2010-06-04T22:19:30Z</DateTimeReceived>
 <Size>2612</Size>
 <Importance>Normal</Importance>
 <DisplayTo>Kent James</DisplayTo>
 <Culture>en-US</Culture>
 <Sender>
  <Mailbox>
   <Name>Postini Support</Name>
   <EmailAddress>noreply@hostedmsexchange.com</EmailAddress>
   <RoutingType>SMTP</RoutingType>
  </Mailbox>
 </Sender>
 <ToRecipients>
  <Mailbox>
   <Name>Kent James</Name>
   <EmailAddress>rkentjames@caspia.org</EmailAddress>
   <RoutingType>SMTP</RoutingType>
  </Mailbox>
 </ToRecipients>
 <From>
  <Mailbox>
   <Name>Postini Support</Name>
   <EmailAddress>noreply@hostedmsexchange.com</EmailAddress>
   <RoutingType>SMTP</RoutingType>
  </Mailbox>
 </From>
 <InternetMessageId>&lt;0c34b5a4-5f3c-4654-bf9d-99c9a8cb439b@HUB02.4emm.local&gt;
 </InternetMessageId>
 <IsRead>1</IsRead>
</Message>

At first it bothered me to save what is essentially a duplicate of what is coming over the wire, but why not? It’s not conceptually any different than RFC-822, or JSON, in function.

Something I’ve found myself doing at work is creating a new filter for every folder I create. I work on technical cases and for each new case number I create a new folder and have all emails with that case number go into that folder.  The crappy part about it is that I literally have hundreds of cases I deal with, and hence hundreds of filters.  You’ve already got the regex match criteria in filtaqulla, I’d love to be able to take that match criteria and use whatever string it matches as the destination folder action criteria. Sample subject line contains the following: 2010-0609-518

One of the features added to my extension FiltaQuilla recently is the ability to add custom javascript actions. I thought that I would give a shot at doing this request as a custom javascript action. The author of the email was expecting this to get linked to the regex search term, but that is not the easiest way to do it. It is easier to just let the filter action also do the regex search.

After installing FiltaQuilla, you need to enable the custom javascript action, which is done on the Addon options page. After that, you can add a javascript custom action in the filter editor.

Then you need to write the javascript code for the action. I’ve done similar work in the past, so that took me about an hour to get correct. Then insert the code into the action field for the javascript action, and it’s ready to go! You have to have some sort of search in the filter as well. You could just search for everything if you wanted, or you could add a regex search for the precise term if you want. It doesn’t matter much, as all of the work is really being done in the action. You just need to make sure that the action gets called for each message that might need to be moved. There’s more documentation of this feature available at the FiltaQuilla page on this site.

The code I came up with is:

let digitsRegex = /20\d\d\-[0-1]\d[0-3]\d\-\d\d\d/;
let acctmgr = Cc["@mozilla.org/messenger/account-manager;1"]
                .getService(Ci.nsIMsgAccountManager);
let copyService = Cc["@mozilla.org/messenger/messagecopyservice;1"]
                    .getService(Ci.nsIMsgCopyService);
for (let index = 0; index < msgHdrs.length; index++)
{
  let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
  let theDigits = digitsRegex.exec(hdr.subject);
  let folders = acctmgr.allFolders;
  let length = folders.length;
  for (let i = 0; i < length; i++) {
    let folder = folders.queryElementAt(i, Ci.nsIMsgFolder);
    if (folder.name == theDigits) {
      let messages = Cc["@mozilla.org/array;1"]
                       .createInstance(Ci.nsIMutableArray);
      messages.appendElement(hdr, false);
      copyService.CopyMessages(hdr.folder, messages, folder, true,
                               null, msgWindow, false);
    }
  }
}

With this filter, if you create a folder with a name like “2010-0616-001″, and your message has that in the subject, the message will get moved to that folder.

If you are having trouble getting it to work, an easy way to debug is just to insert statements like this into the javascript:

Cu.reportError("I am here");

Those printouts will show up on the error console, so you should be able to see if your filter action code is working or not.

Why no header information? Because the header summary, for reasons that I cannot explain, reads the message file directly – and assumes that the message is in RFC 2822 format. But Exchange Server has already done all of that parsing, and separated the message into its components, including metadata (like subject), body, and attachments.

An important issue going forward for the Mozilla Mailnews (Skink) codebase is, what exactly is the thingy that Thunderbird purports to be? Is it a processor of RFC 2822 messages? Or is it something more, that easily incorporates other forms of communications? I hope to write a longer post on that issue soon.

]]> http://mesquilla.com/2010/06/04/reading-the-body-mailnews-exchange-support/feed/ 7 http://mesquilla.com/2010/06/01/lessons-from-google-thunderbird-as-a-firefox-extension/ http://mesquilla.com/2010/06/01/lessons-from-google-thunderbird-as-a-firefox-extension/#comments Tue, 01 Jun 2010 19:39:16 +0000 rkent http://mesquilla.com/?p=829 During my current trek to the Bay Area, I seem to be bombarded with news about Google. I was particularly interested in the different way that Google views its business model, and that got me thinking about how Thunderbird fits into Mozilla’s business model.

In an extensive article in Atlantic magazine (I always read the Atlantic while travelling), James Fallow describes efforts that Google is undertaking to try to revive the viability of news reporting as a professional activity. A lot of this revolves around different methods of bundling content with monetization schemes. In the traditional newspaper model, news is one of many parts of the bundle, with monetization provided by various advertising streams. The internet has provided many ways to unbundle the various pieces of the newspaper, with the result that the hard news content no longer has a sufficient bundling with the monetization schemes.

Google may be viewed as a new kind of bundle, with its many services (search, maps, email, news, etc.) all part of the bundle of services that are attached to the monetization scheme of search advertising. The Atlantic article notes that:

Virtually all of Google’s (enormous) revenue comes from a tiny handful of its activities: mainly the searches people conduct when they’re looking for something to buy. That money subsidizes all the other services the company offers …

That requires a new way of thinking about understanding the relationship of traditional “cost centers” to “revenue”. When Google’s Andy Rubin was asked to justify the expense of Android development in this interview in the San Jose Mercury News, he responded:

So all we have to focus on are those types of innovations that scale for large audiences, and … the revenue crank just turns.

So what is Mozilla’s bundle and monetization scheme, and how does Thunderbird contribute to that bundle?

Mozilla’s main bundle that is attached to a monetization scheme is the FireFox browser, which is monetized through people’s use of a particular search provider when connected through the bundle. Thunderbird (and its related Mozilla Messaging cost center) do not currently contribute anything directly to that bundle and its monetization scheme.

I don’t believe that Mozilla’s subsidization of Thunderbird can continue indefinitely. Perhaps that was possible for awhile, but Mozilla’s bundle can be expected to come under continual competitive attack, which will eventually force them to marshall the resources needed to defend the bundle. Mozilla Messaging and Thunderbird need to be part of the solution, and not just a cost drag, when the tough decisions are being made to defend the bundle.

If we think like Google, it’s pretty obvious what the step is that is needed for Thunderbird to become a major contributor to Mozilla’s main business of “Firefox the bundle”.  We need to figure out ways to attract people to the bundle, and get them to linger as long as possible on the bundle while the “revenue crank just turns.” The obvious solution is that the underlying communications code that drives Thunderbird needs to be repackaged as a FireFox extension. (Since I call that codebase Skink, let’s temporarily use the code name SkinkFox to describe the Thunderbird-as-Firefox-extension product.)  SkinkFox could have the same relationship to Thunderbird that Lightning has to Sunbird: the same product packaged both standalone, and as an extension.

“That’s just SeaMonkey!” you say. Well no it is not. If you think like an engineer and focus on features, then I guess SkinkFox is similar to SeaMonkey. But thinking like a marketer, the goal of this is to build the FireFox brandname and revenue stream, and SeaMonkey does not contribute to that while SkinkFox does.

Technically, great efforts are already being made to reduce the barriers that keep the mailnews (Skink) codebase separate from FireFox. I don’t think it would be a huge leap to figure out how to merge Thunderbird’s user interface and tab system into FireFox’s.

As Thunderbird enters a critical rethinking in the next few months in the aftermath of Thunderbird 3.0/3.1, SkinkFox is one of a variety of thoughts I will be giving on possible futures for messaging at Mozilla.

So here’s a picture to show where I am at. The two messages are real messages that exist on the Exchange server, and have been read by my extension. The message body is not real:

One problem that I had to solve is to make the nsMsgDatabase object extendable. The standard code for that does lots of static casts to the pointer for the XPCOM object, which either caused crashes, or duplicate database caches, depending on the approach that I took to get around that.  I ended up writing a patch for the base code to solve this, which presumably I will land for TB 3.2. I still think there must be some way to cleverly avoid this problem without patching the base code, but I could not figure it out.

I’m not real happy about requiring a base patch for this work, because I had hoped to be able to release a prototype for this on Thunderbird 3.1 / comm-central 1.9.2, even though the main release should be in Thunderbird 3.2/ comm-central 1.9.3. Maybe I can still figure out a solution that does not require a base patch.

Fun with Branding

I’ve talked about the Colonial layer and the Native layer in my application. What’s above the Colonial layer? I want to be able to distinguish between the code shared with Firefox, and the specific code that is used by messaging applications (Thunderbird and SeaMonkey), because I want portions of my work to be loadable into a FireFox extension (just in case). It could be called by the name of the main directory (mailnews) or that directory’s parent (comm-central). Personally I find mailnews very unattractive as a brand. (A bug asks “What’s the name of MailNews?”)

Although I got no traction when I suggested it on m.d.a.thunderbird, I’m going to experiment personally with calling the Mozilla code that implements messaging functionality, and is not included in Firefox, as the Skink layer instead of “mailnews” (following Mozilla’s lizard analogy and Gecko). Yes I am being bullheaded, but this is my personal blog, so I can do what I want, right?

I also managed to register the domain exquilla.com, as ExQuilla is the logical brand for my Exchange Server integration functionality.

]]> http://mesquilla.com/2010/05/21/thread-pane-and-nsimsgdbhdrnsimsgdatabase-mailnews-exchange-support/feed/ 2 http://mesquilla.com/2010/05/20/javascript-custom-filter-action-in-new-filtaquilla/ http://mesquilla.com/2010/05/20/javascript-custom-filter-action-in-new-filtaquilla/#comments Thu, 20 May 2010 17:00:05 +0000 rkent http://mesquilla.com/?p=788 I recently released a new version of FiltaQuilla for Thunderbird and SeaMonkey, and one of its cool new features is a custom filter action that runs arbitrary JavaScript. This relies on new backend features, so you’ll need TB 3.1 beta2 or later for this to work.

Mitra recently pinged bug 249191 asking for a filter action that affects remote content. That looked like a good application of a javascript filter action, so I tried it out.

Looking at the underlying code in nsMsgContentPolicy.cpp, there is a message header property “remoteContentPolicy” that can be used to enable showing of remote content for a message. Unfortunately disallowing content appears more complex, as the address book whitelisting appears to override the message header value. But really I think that allowing remote content on a per message basis is probably the more common action need, so let me demo that.

In my documentation for FiltaQuilla, I show a simple basic javascript example of a custom action that affects a message header subject property:

for (let index = 0; index < msgHdrs.length; index++)
{
  let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
  hdr.subject = "[Hello, world] " + hdr.subject;
}

It’s fairly easy to modify this to set the remoteContentPolicy instead. The result is:

for (let index = 0; index < msgHdrs.length; index++)
{
 let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
 hdr.setUint32Property("remoteContentPolicy", 2);
}

So if you enter this as a JavaScript custom filter in JunQuilla, you can enable remote content on messages controlled by a filter.

I tested it on a spam message that had “Exxon” in the subject. The resulting filter, including the javascript, looks like this:

I’m sure that defining these filters is beyond the skill of all but a few advanced users, but once the code is written it’s pretty much just cut and paste to get this to work. If I collect a few more examples, I suppose I should create a webpage to show them.

Thanks to jcranmer, Standard8, and bienvenu on IRC channel #maildev for helping to point me to the base code that manages remote content policy.

Unfortunately an issue has loomed too large to ignore: the need to sequence a number of SOAP requests when I need to send multiple requests to meet a single goal. Previously I had simply kludged around this, but I needed to make some decisions to be able to move forward in an orderly manner.

I’m also having enormous problems deciding what to name things. So before I can even talk about what I decided to do, I need to give a little lesson on the naming that surrounds my architecture.

Overall Architecture

Since my last diagram, I have clarified things a little, so the structure now looks like this:

The architectural layers are:

Mailnews: the existing Mozilla Mailnews code and objects.

Colonial: the Colonial layer provides the glue between objects represented in Mozilla mailnews format, and Exchange server format. The “colonial” analogy is an extension of the “native” layer analogy presented earlier. That is, if we picture Mozilla mailnews as the mother country, trying to make sense of some aboriginal “native” tribe, then there exists a colonial administration that pretends to have the same laws as the mother country, but has to translate all of those laws into some sort of actions involving native people. So the objects that pretend to be following the laws of the mother country (Mozilla mailnews), but in fact really exist in some other culture, are Colonial objects.

In my architecture, the Colonial objects are subclasses of base Mailnews objects like nsMsgDatabase, nsMsgDBFolder, nsMsgIncomingServer, etc.

Native: This layer’s objects exist as XPCOM objects on the Mozilla platform, but are represented in the native “Exchange” format rather than in Mailnews format. So for example they are identified primarily by string object ids (and not integer keys like Mailnews objects), and they are located in the Exchange tree. For example, folders containing contacts, the inbox, and tasks are all subfolders of a root mailbox folder, as in Exchange Server.

EWS: This layer provides translation of methods to perform operations on native-layer objects (like get subfolders, or sync message metadata) with objects that can be directly translated into SOAP web calls. (I actually use an intermediate representation, called a “property list”, that is very similar to an nsIPropertyBag, but supports ordered, multiple-valued lists such as are present in the SOAP protocols. But these property list objects can be translated directly into the SOAP protocol using the schema provided by Exchange Web Services).

SOAP: As discussed earlier, this is an updated version of Mozilla’s abandoned webservices package.

Exchange: The Exchange Messaging Server itself, implementing a SOAP interface.

State Machine to implement Mailnews Object methods

Let me now describe the problem, and what I decided to do. This is the msqEwsMachine class in the diagram.

The interface to Mozilla mailnews frequently consists of methods that are executed on mailnews interfaces, for example nsIMsgFolder.getNewMessages(). Such methods will get translated into a sequence of requests to a web server, which leave the SOAP layer as a sequence of nsXMLHttpRequests.

Which object is responsible for taking the method call, managing the series of requests to the web server, and generating appropriate events and callbacks when the method has been completed? That has been the issue of the last two weeks.

Originally, I had it done by the colonial-layer representation of nsIMsgIncomingServer, msqEwsIncomingServer. But I did not like how that forced the incoming server object to know way too much about the details of the SOAP calls, when at that layer all it really needed to know was the data results. I also tested using the service layer objects, either the colonial layer object that implements nsIMsgMessageService, or its Native-layer counterpart. But I found that everything that I did needed access to the root of the Native layer data representation, which is the native mailbox object.

So that is where the management ended up: methods on an object, msqEwsMachine, which is fully owned by the the native-layer mailbox object (The mailbox is the native-layer analog of nsIMsgIncomingServer).

A simple request to the mailbox layer would be “discover subfolders”, which requests that the Exchange server provide a list of all defined folders, their parent/child relationship, and some basic folder properties such as the display name. That requires two SOAP requests: 1) a first to translate the so-called “DistinguishedFolderId” such as “inbox” into the guid equivalent for the limited number of distinguished folders, and 2) a second call where the root folder is asked for all of its children recursively. At the end of the whole process, an “onStop” event is generated, which will ultimately be translated into the appropriate mailnews notifications.

Next step: message metadata and nsIMsgDBHdr

Yes this has been a rather boring post, but I didn’t want anyone to think nothing was happening! As the next step, I am now ready to start generating a list of messages per folder, and their corresponding nsIMsgDBHdr objects. Then I can show messages in the thread pane.