MesQuilla

Showing the header (Mailnews Exchange Support)

In my last post, I thought it was going to be tricky to get the message header to display in my Thunderbird Exchange Web Services extension. Turned out it wasn’t so hard after all. After I display the body, I just had to pretend like I was the Mime processor, and spit out headers to an nsIMsgHeaderSink that is listening on the message window. The details of what to do are in nsMimeHtmlEmitter.cpp. The result:

Thunderbird dies a horrible death if I click on any of the actions in the header though. Got to work on that.

Posted in Exchange Web Services (EWS), Mailnews development | No Comments »

Reading the Body (Mailnews Exchange Support)

Just as a status update, my Exchange Server extension can now read message bodies. But note that there is no header information displayed with the message:

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.

Posted in Exchange Web Services (EWS), Mailnews development, Planet Mozilla, Planet MozillaMessaging | 7 Comments »

Lessons from Google: Thunderbird as a Firefox extension!

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.

Posted in Planet Mozilla, Planet MozillaMessaging, Thunderbird's future | 29 Comments »

Thread pane and nsIMsgDBHdr/nsIMsgDatabase (Mailnews Exchange Support)

Now that I have a state machine to handle situations that need multiple SOAP calls, it was not a big leap forward to hookup the SOAP requests to the mailnews summary database. That’s what gets the messages displayed in Thunderbird’s thread pane.

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.

Posted in Exchange Web Services (EWS), Mailnews development, Planet Mozilla, Planet MozillaMessaging | 2 Comments »

Javascript custom filter action in new FiltaQuilla

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.

Posted in Extensions, FiltaQuilla, Planet Mozilla, Planet MozillaMessaging | 3 Comments »