Planet Mozilla Messaging

September 02, 2010

Calendar

How are Lightning users doing in terms of Thunderbird usage

Six month ago, I shared our usage statistics for Lightning with you, which showed that Lightning users on Thunderbird 3.x had surpassed Lightning users on Thunderbird 2.x for the first time.

Now it's time to look at things again and I'm happy to report, that as of yesterday roughly 75% of our users now use a Thunderbird 3.x build as can be seen in the chart below.

It's also important to note that nearly 50% are already using the latest Thunderbird 3.1.x builds, while users of the old Thunderbird 3.0.x series are decreasing fast. This is mostly due to the major update offers of Mozilla Messaging for users of Thunderbird 3.0.x.

Major update offers have recently (last week) also started for users of Thunderbird 2.x, but haven't really been unthrottled yet (throttling means, that currently only 1 in 5 users of TB2 gets a major update offer to Thunderbird 3.1.x). Once major update offers go out to every TB2 user, we expect their numbers to decrease much more heavily. The current state of things (showing the last six months) can be seen in the chart below:

As frequently noted in earlier articles, the ratio of Thunderbird 3.0.x and TB 3.1.x users is much higher on the weekends compared to the Thunderbird 2 users. The graphs show that very well.

For those interested: The "other" number contains users on older Thunderbird 1.5.x builds, SeaMonkey users and users, who have mistakenly tried to install Lightning into Firefox. Generally that number always fluctuates between 0.35% and 0.5% of our total active users.

I hope that you will find this as interesting as I do.

September 02, 2010 08:09 AM

September 01, 2010

Mark Banner

Notificiations added to Tinderstatus

Tinderstatus 0.4 can notify you when a tree state changes, or even particular builds on a tree change state or stay broken:

picture-17

I find this especially useful if I’m tree watching, as tinderstatus does the watching for you - you no longer need to keep examining tinderbox, or tbpl for the next build to change state, tinderstatus will do it for you, and push out an alert (using the gecko alerts system - on Mac this integrates with growl, as you’ll see above).

By right-clicking on Tinderstatus’ icons, you can globally turn on and off the notifications (for periods when you’re not watching the tree or its just too busy). You can also access the preferences where you can configure which trees to give notifications for, and which trees you want to get notifications in more detail about the specific builders.

I had the idea to implement this after seeing Christian’s pulse.mozilla.org and realising that I was doing a lot of context switching whilst watching the tree to keep looking at the web page. I realised a notification system would push the information to me rather than going to have to look (and maybe reload) a web page myself - what was even better is that I realised that although pulse.mozilla.org is still under development, I could easily add notifications to Tinderstatus. So I did.

I hope the tree watchers out there find this useful, improvements are always welcome, tinderstatus can be found on mozdev.

September 01, 2010 10:38 AM

Trustedbird News

S/MIME signed receipts in Trustedbird 3.1

Trustedbird

A new branch of Trustedbird based on Mozilla Thunderbird 3.1.2 has been released.

As for now, Trustedbird 3.1 implements only S/MIME signed receipts. This feature is described in Enhanced Security Services for S/MIME (RFC 2634 - section 2).

The client is able to request a receipt in a S/MIME signed message. It can also reply to a receipt request by sending a signed receipt.


Trustedbird 2 has also been upgraded and is now based on Mozilla Thunderbird 2.0.0.24.


Signed receipts screenshots

⇒ More information about Trustedbird

--10:11, 1 September 2010 (CEST)

September 01, 2010 08:14 AM

August 31, 2010

Robert Kaiser

Weekly Status Report, W34/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 34/2010 (August 23 - 29, 2010):

Our statistics on active daily SeaMonkey 2.x installations have been stagnating since the start of the holiday period in July, but this last week have been returned to increasing significantly, and on Saturday, we had our over-a-week average going over 90,000 active daily installations, just to have the single-day value break the 100k barrier the first time ever two days later, i.e. yesterday.
This is an important milestone to hit and tells us we're going strong, but what I'd really like is to have ten times that number, i.e. a million people starting SeaMonkey 2.x every day. Can we hit that? Can you talk 9 more people into using SeaMonkey 2.x? If each of our users can, we should be able to make it - in theory. Will you take the challenge?

August 31, 2010 08:09 PM

August 30, 2010

Thunderbird Localization

Resignation as Thunderbird l10n contact

Hi everyone,

it's really hard for me, but I've decided to resign from my role as Thunderbird l10n contact as of today (Monday).

Within the last six months it has become clear to me, that I'm not able to do the job adequately anymore, as my time has been more and more occupied with matters related to my private life and my day job. Therefore I've not been able to dedicate as much volunteer time to this role as I would have liked or hoped.

I don't want to fill a role any longer, where I'm not satisfied with my performance and where a motivated person with more time on his/her hands could really make the difference, that I can't make anymore.

Right now I'm working on a transition plan with the folks of Mozilla Messaging. Once a new person takes over, I'll make sure to be available and help him/her with ramping up in the new role. If anybody is interested in picking up some or all of this work, we (meaning Mozilla Messaging or me) would love to talk to you.

I've written up a list of things, that I've performed regularly in this role to give people an impression of what's involved. The list is available here.

If you are thinking about taking on this job, let me tell you in short what makes it so rewarding:
I think being part of a team and being responsible for bringing TB to new people in new markets is particularly rewarding. When I look back and see that we had 38 locales with TB2, are now at 52 and have the potential to reach 80 locales, I see a lot of potential new TB users, which the l10n coordinator would at affect. Working with so many different people (localizers, developers, users) is also something that I've always thrived on. So please get in touch!

It's been a real pleasure working with all of you.

PS: I will also resign from my different roles in the Calendar Project. Please see this blog post for more information.

August 30, 2010 01:39 PM

Calendar

Resignation from the Calendar Project

Hi everyone,

it's really hard for me, but I've decided to resign from my different roles in The Calendar Project (mainly as webmaster and l10n contact) as of today (Monday).

Within the last six months it has become clear to me, that I'm not able to do the job adequately anymore, as my time has been more and more occupied with matters related to my private life and my day job. Therefore I've not been able to dedicate as much volunteer
time to this role as I would have liked or hoped.

I don't want to fill a role any longer, where I'm not satisfied with my performance and where a motivated person with more time on his/her hands could really make the difference, that I can't make anymore.

I'm currently working with Philipp, our lead developer, on a transition plan. Once a new person takes over, I'll make sure to be available and help him/her with ramping up in the new role. If anybody is interested in picking up some or all of this work, we (meaning Philipp or me) would love to talk to you.

I've written up a list of things, that I've performed regularly in this role to give people an impression of what's involved. The list is available here.

In my eyes, the Calendar Project is a project, where one person can really make a difference, unlike in large projects as Firefox, where the impact of one person is often just a drop in the sea. So please get in touch!

It's been a real pleasure working with all of you

PS: I will also resign from my role as Thunderbird l10n contact. Please see this blog post for more information.

August 30, 2010 01:19 PM

Rumbling Edge - Thunderbird

2010-08-29 Calendar 1.0 builds

Previous Lightning release (1.0 Beta 2) | Next planned Lightning (1.0 beta 3?) | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Common (excluding Website bugs): (25)

Outstanding bugs (marked blocking-calendar1.0+): (88)

One can get the latest Lightning .xpis here.

Sunbird will no longer be actively developed by the Calendar team.

August 30, 2010 08:56 AM

2010-08-29 Thunderbird comm-central builds

Previous TB release – 3.1.2 | Current TB pre-release – 3.2a1? | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Thunderbird-specific: (32)

MailNews Core: (41)

Outstanding bugs (marked blocking-thunderbird3.2 marked as “alpha1+” - tentative query): (0)

Windows builds Official Windows, Official Windows installer (discussion)

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac (Universal binary) (2010-08-28 build)

August 30, 2010 08:24 AM

2010-08-06 Thunderbird comm-central builds

Previous TB release – 3.1.2 | Current TB pre-release – 3.2a1? | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Thunderbird-specific: (26)

MailNews Core: (15)

Outstanding bugs (marked blocking-thunderbird3.2 marked as “alpha1+” - tentative query): (0)

Windows builds Official Windows, Official Windows installer (discussion)

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac (Universal binary)

August 30, 2010 08:17 AM

Thunderbird 3.1.2 Released

Changelog for previous release (Thunderbird 3.1.1) | Changelogs for other Thunderbird releases

Released on 05 Aug 10, and this changelog was last updated on 07 Aug 10.

Thunderbird 3.1.2 has been released. Release notes are available. This post lists the improvements in Thunderbird 3.1.2 over Thunderbird 3.1.1. This list encompasses almost every single known fix that went into this release, but excludes platform-wide fixes. Do check out the known issues as well.

Impact key for security issues (fixed in this version – none at time of listing) that are listed on the Mozilla Foundation Security Advisories webpage:

Other changes in Thunderbird 3.1.2: (6)

Thunderbird-specific: (3)

MailNews Core: (3)

Windows builds Official Windows installer

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

August 30, 2010 07:20 AM

August 27, 2010

Dan Mosedale

new blog & MuteThread add-on for Thunderbird

Last week, while I was off on vacation, I set up a new blog for myself over at http://redpuma.net/blog/.

I've just now posted there about the MuteThread add-on for ignoring email threads that I've made available on addons.mozilla.org.

Since my new blog isn't yet known to Planet Mozilla or Planet Mozilla Messaging, I figured I'd add a pointer here so that folks would actually see it. :-)

August 27, 2010 11:48 PM

August 26, 2010

SeaMonkey Trunk Tracker

2.1 Alpha 3 Roundup

Here it is, with a small delay: The SeaMonkey 2.1 Alpha 3 Roundup.

Since the last alpha, some major changes appeared on trunk. KaiRo was especially busy, landing both Places-based bookmarks and Lightweight Themes (Personas) support for the browser, and his Data Manager integration has already gone through several reviews. As always, the SeaMonkey 2.1 features page gives a good impression of the overall progress.

Developers will surely appreciate that the JavaScript Debugger (Venkman) is usable again after the XPCOM components registration changes broke it.

For the platform changes, have a look at the Firefox Beta release notes (b2, b3, b4).

Progress:
MailNews: Address Book: Bookmarks: Download Manager: Help: DOM Inspector:
JavaScript Debugger (Venkman): Audio/Video:
Preferences: Add-on Manager:
Linux: Mac: Compiling: General: Platform:

August 26, 2010 10:46 PM

August 25, 2010

Blake Winton

More secure!

As someone who works on an email client, I’m interested in making my communications more secure. So, with the assistance of Ludovic and Gozer, I got a client certificate that would allow me to sign and encrypt my messages. (Check out the envelope and lock in the image below.)

An outgoing message, with an envelope and a lock

Most of the time, I’ll probably just sign my messages – after all, that’s what I’ve set it up to do by default – but it’s nice to know that if there’s something I need to encrypt, that option is now available to me.

August 25, 2010 09:34 PM

SeaMonkey

SeaMonkey 2.1 Alpha 3 Available

SeaMonkey 2.1 Alpha 3 marks a third preview milestone on the way to the future of Mozilla's SeaMonkey Internet suite and is now available for free download. Please note that this pre-release version is still intended for developers and testers only. As always, we appreciate any feedback you may have and encourage
users to help us by filing bugs.

The new improvements of this developer preview compared to the last one include:


We welcome any and all discussions on this alpha on our newsgroups, or you can even file a bug if you find one. Be sure to check our Known Issues prior to filing bugs.

SeaMonkey 2.1 Alpha 3 is available for free download on the SeaMonkey website. Once you have downloaded and installed this release, we'd like to encourage you to get involved in discussing and reporting problems as well as further improving the product.

Thanks for testing and helping us to make SeaMonkey even better!

August 25, 2010 01:40 AM

August 23, 2010

Robert Kaiser

Weekly Status Report, W33/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 33/2010 (August 16 - 22, 2010):

This has been a really busy week for me - actually, when writing this up today, it looks even more busy then it felt while it was underway. Unfortunately, we didn't get as far as I hoped on the third alpha, but I hope we'll be able to push it out to the public in the next few days, so our full concentration can be on the beta development cycle. A lot of work has already happened, and some more stuff is underway - both in SeaMonkey-specific code and in the platform, so it feels really great to be in the project right now - even if not always everyone agrees on specifics, but I'm sure we can work out a lot of that to a degree where we all can be happy. And where we still diverge in what we want - well, that what prefs and add-ons are for, after all! :)

August 23, 2010 06:52 PM

August 20, 2010

Trustedbird News

Thunderbird 3.1 compatibility for MDN Extended

MDN Extended, the add-on which permits to send a return receipt (MDN) on message deletion, is now compatible with Thunderbird 3.1.


⇒ Download MDN Extended 1.2.0

--12:27, 20 August 2010 (CEST)

August 20, 2010 10:30 AM

August 18, 2010

Kent James

Towards an Alpha supporting Thunderbird 3.1 (Mailnews Exchange Support)

Things have been a little slower lately, what with summer and family visits and so forth, but my project to support Exchange server in Thunderbird proceeds nevertheless. I’m starting to think seriously of an Alpha release.

Originally I had assummed that there would be changes required in core to support what I am doing. But so far, that has not been absolutely necessary. I had problems earlier with the database code, but I’ve managed to get around that by just using a standard nsMailDatabase object instead of doing my own version.

So I tried to build a version that could run on current Thunderbird 3.1 releases. That required staring at the build code for a couple of weeks, which I guess is the price that I pay for writing much of this extension in C++.  In the end, the magic that I needed was surprisingly simple:

ifndef MOZ_STATIC_MAIL_BUILD
 EXTRA_DSO_LIBS = msgbsutl
 else
 SHARED_LIBRARY_LIBS =
   $(DEPTH)/mailnews/base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX)
endif

I am now running my EWS extension with my normal Thunderbird profile – but I have not had the courage yet to use the email address for anything real. Fortunately, the spammers of the world have discovered my test address rkentjames@caspia.org, and are kindly providing me with a wide variety of test emails.

The question I have now is what is the minimum functionality required for an alpha release. I’ve recently added the ability to read attachments from my Exchange messages, but I don’t yet have the ability to create emails that contain attachments. I think that after I add that ability, I will have a basic email read/write capability, and will stop adding features and concentrate on fixing annoyances prior to releasing an alpha.

I’ll still be missing a zillion features, including:

and a whole lot more. But the alpha application could be used to do a basic check of someone’s work email from a home Thunderbird installation.

August 18, 2010 06:57 PM

Mark Banner

Revised super-review policy for comm-central

Following a period of discussion, comm-central is adopting the same super-review policy as mozilla-central. There are two exclusions to this: the suite/ and calendar/ directories which are covered by their own policies (suite/, calendar/).

The updated rules for comm-central reviews can be found here. We are also in the process of updating the super-review policy page to reference comm-central and the exclusions.

August 18, 2010 11:07 AM

August 17, 2010

Ludovic Hirlimann

Weird interaction between personas and an extension

I've been using Firefox 4.0b3 for a week or so now. As always when I switch to beta, I usually loose some functionality due to some extensions not being validated with the version of Firefox that I use. I've been using delicious to manage my bookmarks for the last two or three years, because it enables me to share my bookmarks (and I don't have a lot) with other computers, other browsers and with my friends (yes I'm a web social beast).

So this morning I was clearly happy to see that the delicious team had a nice extension in beta for me to try out. I was all happy about it and installed it. My bookmarks where back in place ;-) I then noticed that I had lost mouse gesture. I disabled the extension and woot mouse gesture was back. I then send a little email as a piece of feedback to the delicious mailing list.

Two hours later I was contacted on instant messaging by the Yahoo developer. And we tried to figure out what was going on. The only thing That was left was my personas theme. So I went to getpersonas.com , I then noticed that it solved my mouse gesture issue. Restarted Firefox and yet again lost gesture until I opened getpersonas.com in one of my tabs. So I have this weird bug about an extension, a theme that will work together if I load the web site where I got the extension from, I'd love to file a bug, but I have no idea, where/why/how.

August 17, 2010 10:12 AM

August 16, 2010

Robert Kaiser

Weekly Status Report, W32/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 32/2010 (August 9 - 15, 2010):

Post-places landing talks, planning for the future, and driving SeaMonkey 2.1 Alpha 3 ate up a lot of this week, so doorhanger notifications and Data Manager stagnated mostly, but I hope to pick up work on those this week again.
That said, despite some regressions that need a respin and places bookmarks definitely having some rough edges, this upcoming last alpha sounds like it will be a very great one, showing up a really good number of new things and making a stand for this project moving forward significantly.
That said, your testing and feedback is needed and wanted very much! :)

August 16, 2010 07:36 PM

August 15, 2010

Robert Kaiser

The Cloud And The Pocket

In recent months and years, I have heard an increasing number of people putting forward opinions that "in the future, nobody will have local data, everyone will have all his/her data in the cloud".
Now, I don't think this extreme will really be reached, I'd even go as far as to believe we'll have most or all of our data and probably a good part of our computing power in our pocket instead.

Right now, the primary argument for putting things into the cloud is that people want to use their data from different desktops, maybe their smartphone, possibly some tablet, and all those have web access, so the cloud can be accessed from all those machines, and the same way. Of course, that only works really well when you're on broadband. Still, this is nice to have, and who cares about the cloud provider reading your data for better ad placements and selling data to third parties anyhow. You are on Facebook as well, right? OK, so why should you care about your data being sold or analyzed for better ads in one more place? After all, it wins you a lot of comfort, and that's what counts.

Let's assume for a moment that those problems are all moot. And the problem that there are places where your phone or tablet doesn't get any or only a bad connection, intentionally or unintentionally, be in in some deep basement bar (like the one I'm going to frequently) or far out in the US country, in deep valleys or up on mountains, where it's too expensive to put transmitting stations for phone providers because of too few people or too many reflections and too little direct reach. Let's ignore all that for the moment. Let's also ignore that your cloud provider could just go bankrupt or stop its services for other reasons.

I still think a different model of data storage will feel better for most people once all parts of the concept are there - which will not be the case in 2010, probably more in 2015 or 2020.

Imagine your smartphone, lets say some neat package similar to the current iPhone or N900, basically a small screen which not much else, possibly a mini-keyboard if you like, will have as much computing power and more storage space than a current desktop (which, given what we've seen in the last 10 years, is not unrealistic). Imagine you could have tablet-like screen rolled up in your backpack and put up to a normal tablet screen within a few seconds, and you smartphone would just connect to that and act as the processing and data unit for it. Also, imagine that instead of a desktop, you would have just a large screen on your desktop, along with whatever input devices will be your choice (currently probably keyboard and mouse for most people, but who knows what we'll have then) - and your smartphone will seamlessly connect to that and act as data unit and possibly processor, perhaps in cooperation with some stronger processor unit integrated with the big screen or some other extension device on your desk. Even more, imagine that in cafes or on airports, there will be such computing stations you can seamlessly connect your smartphone, er mobile computer, to.

Now, having your data and processing power in your pocket, using the same software across all those machines, be it an OS, web browser, web app, local app, hybrid, or whatever, why again would you want to store all your data in the cloud?

Sure, there are still reasons, like sharing with others, where the cloud can be helpful, and you sure will want your mobile data to be synchronized with those parts of cloud data. The cloud surely has its good use cases, even in that possible future, but I don't think most people will want to have all their data and their private stuff all up there, esp. when they can and will have it in their pockets and just as ubiquitous instead.

And I doubt the connection to the cloud will ever in near decades satisfy the speed we'd want to edit our videos in the quality we really want to achieve. ;-)

Still, the pocket devices I imagine and all that infrastructure around it will need some time to come into existence (nothing of that sounds really impossible even today, though), so there will be some time where the cloud can continue to shoot ahead in the uses cases of oneself having access to the data everywhere - but I'm looking forward to the pocket taking its bold steps into a quite interesting future!

August 15, 2010 09:26 PM

August 14, 2010

Robert Kaiser

Getting Back on the Road

Back in June, I wondered if the whole year might be travel-free for me - the good news is that it won't. After 10 months of being here in Austria, I'll get back to meeting other Mozilla contributors again.

The story behind that earlier blog post has not gone away though, black clouds are still hanging over my head, but one of those upcoming trips might lift those a bit as well, I hope. After all, that's a good reason why a number of developer meetings are done, as kernel developer Ted Ts'o puts it:
Quote of Ted Ts'o:
One of the primary reasons why I started the kernel summit ten years ago was because I've found that people work better after they have had a chance to meet each other face to face. If you only know someone via e-mail, it's lot easier to get into flame wars. But after you've met someone, broken bread and drunk beer with them, it's easier to work with them as a colleague and fellow developer. While the Linux Kernel development community has grown significantly since March, 2001, this principle still holds true.

There's still a month to go, but first, I'll be at a German community meetup in Cologne in September, and I'm really looking forward to meeting those folks, even when talking German at a Mozilla meeting will feel strange. I also hope that the German-language Mozilla Planet will up up by then so that we'll make sure everyone there who has a blog will be syndicated there. :)

Two weeks after that, I'll take a trip to Mozilla headquarters and will be there or in and around the SF Bay Area from October 4 to 15th.
There will be a number of people to talk to regarding upcoming SeaMonkey plans, our position in the community and our dealings with the future of the Internet, but I should have enough time remaining to just hang around the office for some time and be available for all kinds of talk and chatter, so if you happen to be in MV or the Bay Area at that time, please tell me so we can set up something - or just catch me there. Also, if you have any personal ramblings with me, please take the chance so we can clear those things up in person - we don't have to love each other, but it would be good if we can get along, given we all are working for a better Internet and the overall Mozilla mission.

And probably a short time after that (we are still in negotiations about financing, etc. and have not confirmed the date yet), there will be a long-awaited meeting I won't have to travel to very far - we are planning for a SeaMonkey Developer Meeting with 20-25 people from our community right in Vienna, Austria (Wien, Österreich)!

I'm looking forward to meeting all those people at those different places, being productive in different directions, and getting thoughts to flow on how to tackle the future (well, "tackle" might be the wrong word, we're not in the defense here, but being offensive about it, so how about "receiving" it?) and I'll also very much enjoy the change of pace and places along with those events, as that almost always helps being creative and working for a better common future for all of us!

August 14, 2010 07:01 PM

August 13, 2010

Andrew Sutherland

test-case-mode support for jetpack unit tests in emacs

Use Jetpack?  Occasionally write unit tests so you won’t be a complete hypocrite when criticizing other people’s code?  Think that picture up above looks more useful than this?:

error: fail: list contents ("4,5,6,7" != "3,4,5,6,7")
info: Traceback (most recent call last):
  File "resource://wmsy-jetpack-core-lib/timer.js", line 57, in notify
    this._callback.apply(null, []);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 257, in anonymous
    timer.setTimeout(function() { onDone(self); }, 0);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 282, in runNextTest
    self.start({test: test, onDone: runNextTest});
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 300, in start
    this.test.testFunction(this);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 57, in runTest
    test(runner);
  File "resource://wmsy-wmsy-tests/test-vs-static.js", line 37, in anonymous
    slice.seek(6, 2, 2);
  File "resource://wmsy-wmsy-lib/wmsy/viewslice-static.js", line 51, in anonymous
    this._list.slice(this.bufLow, this.bufHigh));
  File "resource://wmsy-wmsy-tests/test-vs-static.js", line 31, in anonymous
    "list contents");
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 229, in assertEqual
    this.fail(message);
  File "resource://wmsy-jetpack-core-lib/unit-test.js", line 147, in fail
    console.trace();

Then do I have an .el for you!  This lives here.  You mileage may vary and may involve things catching on fire which can, in turn, affect your mileage.

August 13, 2010 05:03 PM

August 11, 2010

Philippe M. Chiasson

Thunderbird gets a new, shiny Try Server!

A long time ago, when the Mozilla Try Server was almost brand new, we took it, applied a generous amount of duct tape to it, and called it the Thunderbird Try Server.

It worked, but barely. Since then, the Mozilla #build folks did an amazing job adding new features to theirs, fixing bugs, and making it more awesome in general. Unfortunately, the Thunderbird Try Server stayed behind, the way it was. Bugs against it were piling up, especially from folks using both try servers and noticing all the missing features compared to the Mozilla Try Server.

All this is about to change! The Mozilla Messaging Build team has worked on recreating a try server with all the new features (and codebase) that runs the Mozilla Try Server.

On Thursday, we'll be switching over to the new try server. What does this mean?

By just doing:

$> hg push -f ssh://hg.mozilla.org/try-comm-central/

from a comm-* checkout, you'll be able to trigger try builds. It's that easy!

For more detailled instructions, you can just refer to the Mozilla Try Server documentation, just use /try-comm-central/ where it says /try/, that's the only difference. Also check the Mozilla Messaging Try Server wiki page, for documentation specifically about our try server (not updated yet)

Right now, we will only be running regular builds and mozmill runs, as the other type of builds are all waiting on the libxul work to complete before they can be made to work easily. Also, there are various features that we want to see in our try server that will not be done, but they will be tackled one by one over the upcoming weeks.

There are 2 important thing to note. The first one is that we'll be turning off the web interface for our try server that allowed for arbitrary patches to be submitted. It was a mess of code, and would simply not work right in this new push-to-try way of doing things.

I know the Mozilla #build folks are working on a new, shinier web interface to their try server, and once they do, we'll just port it over as well.

The second thing (and I suspect many will be happy about that) is that since push-to-try works via hg.mozilla.org, there is not going to be a need for a special certificate to gain access to it. Anybody who already has hg.mozilla.org access gets automatic access to our try server!

As before, you will be able to follow the status of builds on the ThunderbirdTry tinderbox tree.

For bugs specific to our try server, you can file bugs under Mozilla Messaging > Try Server

August 11, 2010 08:36 PM

Ludovic Hirlimann

Changing irc nick

I'm now Usul instead of _Tsk_ on irc.mozilla.org. It's one character shorter. It was available, and I'm a fan so I took it. I did that while watching the Dunes series on TV. I now have a nick that people can pronounce, I sure nobody will pronounce it the same way :-)

August 11, 2010 01:41 PM

August 10, 2010

Instantbird

Status update

We've been a bit quiet since the 0.2 release, but we haven't slept all of this time, so let's do another status update!

After some time spent polishing the new website and dealing with post-release work (like testing and enabling major updates), we have started working toward Instantbird 0.3:

Development is slower than usual this month, because some members of the team, including myself, are taking some time away from the Internet.

In the relatively near future, we will finish the work to switch to Mozilla 2.0, and upgrade libpurple to the latest released version (2.7.*).

August 10, 2010 10:05 PM

Roland Tanglao

Quick Filter Screencast by FuzzyFox

Mozilla community contributor, fuzzyfox, has created a very nice screencast that explains the Quick Filter Toolbar in Thunderbird 3. Check it out!

Got your own screencast that explains Thunderbird? Or do you have favourite one that explains Thunderbird? Then let me know in the comments and I’ll post about the best ones here.

August 10, 2010 09:56 PM

August 09, 2010

Andrew Sutherland

(clicky.visophyte.org-hosted CouchDB services offline)

This means doccelerator and my Tinderbox scraper that chucked stuff into a CouchDB for exposure by a modified bugzilla jetpack.  Either couch went crazy or someone gave it a request that is ridiculously expensive to answer with a database the accumulated size of the tinderbox database.  I’m not aware of any trivial ways to contend with the latter.  Judging by the logs, it looks like 2 people other than myself used these services, so, my apologies to those cool, insightful, forward-looking individuals.

The specific services are probably not coming back.  doccelerator is being subsumed into something else that better meets documentation needs and will be more fully baked, more on that soon.  I got the impression at the summit that the tinderbox problem is in hand, or very close to someone’s hand; maybe one of those robot grabby-arm things is involved?  My reviewboard with bugzilla hacks instance is sticking around for the time being, but I think wheels are turning elsewhere in Mozilla on that front too, so hopefully my install is mooted before it falls over.

Lest there be any doubt, all clicky services are provided on a self-interested basis… I am happy when they benefit others, but I do these things for the benefit of my own productivity/sanity and they are hosted using my own resources.  (While I had higher hopes for doccelerator, the MoMo-resourced couchdb service provisioning never happened so doccelerator never got pushed public with nightly updates because of said clicky resource constraints.)

August 09, 2010 07:05 AM

August 06, 2010

Rumbling Edge - Thunderbird

2010-08-06 Calendar 1.0 builds

Previous Lightning release (1.0 Beta 2) | Next planned Lightning (1.0 beta 3?) | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Common (excluding Website bugs): (1)

Outstanding bugs (marked blocking-calendar1.0+): (92)

One can get the latest Lightning .xpis here.

Sunbird will no longer be actively developed by the Calendar team.

August 06, 2010 07:32 PM

August 04, 2010

Messaging Add-ons

Thunderbird Contacts

Welcome to our second add-on release! This is our first release of a new add-on called Thunderbird Contacts.

Thunderbird Contacts was started by the Mozilla Labs team as Firefox Contacts, an experiment with contacts inside the browser. We’ve adapted their add-on to work inside of Thunderbird and added some new features just for Thunderbird.

The goal of add-on is to experiment in evolving the address book of Thunderbird beyond what it currently is today. Thunderbird Contacts isn’t a standalone address book, instead it understands that your contacts live on the web as much as they do inside Thunderbird. The add-on can pull in contact data from various services where your contacts already exist.

Currently it connects with the following services:

How it works

When you install the add-on you’ll be shown this list of services. You can connect to whichever services you’d like to pull in contacts to your local Thunderbird.

As you pull in contacts from each of the services Thunderbird Contacts will attempt to merge the same contacts from different services into a single contact.

Then as you view contacts the add-on will go “spider” out to various services for more information about your contact; this can find flickr photos and websites for the person.

What’s Next?

Future versions of this add-on will likely experiment with organizing the contacts in different ways. Right now there’s a simple list or card like view and we’d like to take those interfaces further. If you have any thoughts or comments let us know in the feedback channel. If you’re interested in trying something just fork the code and start working.

For more information and a screen cast explaining the add-on check out the Thunderbird Contacts project page.

August 04, 2010 11:18 PM

Trustedbird News

CardDAV available in DavMail gateway

DavMail

CardDAV, an address book client/server protocol (vCard over WebDAV) designed to synchronize contact data, is now available in DavMail gateway since version 3.8.0.

The development of this new feature in DavMail has been sponsored by the French Ministry of Defense through the Trustedbird project.

DavMail is a POP/IMAP/SMTP/CalDAV/CardDAV/LDAP Exchange gateway allowing users to use any mail/calendar client (e.g. Thunderbird with Lightning) with a Microsoft Exchange server, even from the internet or behind a firewall through Outlook Web Access webmail (OWA) or Exchange Web Services (EWS). DavMail is a free software implemented in Java and distributed under the GNU GPL license.

CardDAV can be used in Thunderbird with the SOGo Connector add-on.


⇒ Download DavMail

--09:29, 4 August 2010 (UTC)

August 04, 2010 09:29 AM

August 03, 2010

Trustedbird News

Multi-LDAP add-on is now compatible with Thunderbird 3.1

The Multi-LDAP add-on, which enables Thunderbird to use several LDAP directories simultaneously for address autocompletion, has been updated and is now compatible with Mozilla Thunderbird 3.1.

Several bugs have also been fixed and LDAP session management has been improved.

MultiLDAP.jpg

⇒ Download Multi-LDAP 1.1.4

--08:48, 3 August 2010 (UTC)

August 03, 2010 08:48 AM

July 27, 2010

Roland Tanglao

Thanks to SuMoMo Early Adopters

Even though SuMoMo doesn’t yet have a real localization dashboard (we’re working on it in bug 549407) and hasn’t been announced in the localization news groups, many folks have contributed to SuMoMo (check out the full list of SuMoMo contributors as of July 20th, 2010).

This is just a quick blog post to say thanks! And an official post on the l10n news groups is coming soon. Thanks to all localizers for their patience with the delay.

July 27, 2010 11:39 PM

July 26, 2010

Siddharth Agarwal

js-ctypes

Over the weekend, I decided to learn js-ctypes. The best way to learn an API is by using it for something non-trivial, so I wrote a patch to move a bit of code calling Win32 functions I had written a few months ago from C to JavaScript. Overall, I was pleasantly surprised at how simple it is to use.

Other than these two things, if you already have the C code in front of you, translating it to JavaScript line by line is quite straightforward. I didn’t deal with callbacks, so I’m sure there will be some added complexity there.

July 26, 2010 05:57 PM

July 25, 2010

Instantbird

Major update to Instantbird 0.2

As no critical issues have been reported in the recently released Instantbird 0.2, we have turned on major updates for users of Instantbird 0.1.2 and 0.1.3. If you are still using one of these old versions, you will receive a major update offer to get the newer Instantbird 0.2. It will look like this:

Major update offer dialog

Unfortunately, due to a bug of the updater that shipped in the Windows version of Instantbird 0.1.3.1, the update won't be automatic for these users, who should download the full installer themselves. We are sorry for the inconvenience.

July 25, 2010 08:59 PM

July 24, 2010

Andrew Sutherland

ediosk: an emacs buffer switcher for the rest of us

Emacs users and would-be emacs users, are you tired of those emacs developers in their ivory towers not supporting buffer switching via touch-screen on a computer that’s not running emacs and using modern web browser technology instead of disproven parentheses-based technology?  Be tired no more!*

Thanks to Christopher Wellons and Chunye Wang’s work on emacs-httpd it is a simple matter to expose a JSON representation of the current set of frames/windows/buffers in your emacs session and provide non-REST manipulation mechanisms via a webserver implemented in elisp.

Once you have exposed an API, it is a subsequent simple matter to implement some JavaScript that understands these things and presents a nice UI.  In this case, we have used the Jetpack SDK, wmsy (the Widget Manifesting SYstem, an widgeting framework I am developing), and protovis.

The screenshot basically captures the entire feature-set:

* This entire paragraph is a joke**; no flaming necessary.

** ediosk is not a joke though.  I seriously have a touch-screen monitor hooked up to my windows build machine to the right of my two monitors hooked up to my linux/primary development machine.  While c-x b (icicle mode) will still be my dominant buffer switching mechanism, I expect ediosk to prove useful/amusing for cases where the number of buffers greatly exceeds my mental stack, when I am switching contexts, or when I am working in multiple branches simultaneously.

July 24, 2010 09:32 AM

July 23, 2010

James Burke

Simple Modules Feedback

Executive summary, with apologies to Jay-Z: "I got 99 problems but lack of lexical scoping ain't one".

While at the Mozilla Summit, I saw Dave Herman's presentation on a Simple Modules proposal for JavaScript/ECMAScript. Dave posted the slides, and be sure to read his follow-up post. I suggest you read his slides and blog posts first for some background.

[Sidenote: I'm going to use JavaScript instead of ECMAScript in this post -- JavaScript and I go way back, before it got its colonial, skin disease-inspired name.]

Simple Modules is a strawman proposal at the moment, it is still a work in progress. Some of the more interesting parts for me, the dynamic loading, are still very rough and in a separate proposal. It sounded like Dave wants to focus on prototyping the lexical scoping and static loading bits first before proceeding further on the dynamic bits. Great idea on actual prototyping, sounds like they will leverage Narcissus for doing the prototyping.

So some of my feedback may be a bit premature, but some of it gets to why there are modules and what should be allowed as a module, so hopefully that might be useful even at this early stage.

First, some perspective on where my feedback comes from: I am a front-end developer, I do web apps in the browser. I love JavaScript, I want to use it everywhere, and I believe that it is the only language that has the potential to be used effectively anywhere.

However, that is only because JavaScript is available and works well in the browser. Any new solutions for modules should *work well* in the browser to be considered a solution. The browser environment should be treated as a first class citizen, keeping in mind the browser performance implications on any approach. This is one of my main criticisms of CommonJS modules, and the reason I write RequireJS, a module loader that works well in the browser. I also maintain Dojo's module loader and build system.

Why

Why have modules? What are they? Modules are smaller units of code that help build up larger code structures. They make programming in the large easier. They usually have specific scope, and avoid dumping properties into the global scope. Otherwise the likelihood of a name collision between two modules is very high and errors occur. So a module system has syntax to avoid polluting the global space.

There also needs to be a way for modules to reference other modules.

Simple Modules

The Simple Modules proposal outlines a Module {} block to define what looks like a JavaScript object as far as inspection (for .. in notation, dot property referencing), but is something more nuanced underneath.

Anything inside the Module {} block is not allowed to use a global object, and you cannot add/change a Module after its definition. Here is a sample module, called M, that demonstrates some of the syntax and scoped variable implications:
module M {
//In normal code this would define a global,
//but not inside the module declaration. This
//is likely to be an error(?) in Simple Modules.
foo = "bar";

//color is only visible within module M's block
var color = "blue";

//Creates a publicly visible property called
//"name" on the module.
export name = "Module M";

//setColor is only visible within module M's block
function setColor() {}

//Creates a publicly visible property called
//"reverseName" on the module whose value
//is a function
export function reverseName() {}
}
You can reference/statically load other modules via load (syntax is just a placeholder, not set in stone):
module jQuery = load “jquery.js”;
The goals with this approach:
  1. Stronger lexical scoping: no eval or with allowed in the modules, and a loaded module shares some lexical scope with the module that loaded it.
  2. No access to a global object by default.
  3. Hopefully better syntax for declaring modules over the existing function-based module pattern.
To the extent that modules help programming in the large, the simple modules approach do not give me anything more than I have now, and the proposal has some specific weaknesses. I can appreciate there are some juicy things in the proposal for JavaScript engine developers, but as a user of modules, I do not see it as a net advantage. Here is why:

Lexical scoping/Global access

In addition to using the function-based module pattern to avoid leaking globals, I use JSLint to avoid accessing globals and the use of eval/with. For programming in the large, JSLint helps even more because it enforces a code style that produces much more uniform code. It is built into many editors and easy to run as part of build processes.

JSLint is not perfect (I would like to see JavaScript 1.7/1.8 idioms supported, like let and for each), and you may not like some of the style choices. However, reproducible, consistent style that can be checked automatically is more important than bikeshed-based style choices. It warns of global usage, eval and with, and even helps you find unused local variables.

What is even nicer is that you can opt out of some of the JSLint choices, you can use some globals if you need to. There is some flexibility in the choices.

Functions as Modules

For #3, better syntax for module definitions, I do not see it as a net win over the function(){} module pattern, particularly how it is used for modules in RequireJS where it encourages not defining global objects.

The Simple Modules syntax does not allow exporting a function as the module definition. This is a big wart to me. Functions are first class entities in JavaScript, one of its strongest features. It is really ugly to me that I have to create a property on a module object to export a constructor function, or some module that lends itself to being a function:
module jQuery {
export jQuery = function () {};
}

/*** In some other file ***/
module jQuery = load “jquery.js”;
//ugly
var selection = jQuery.jQuery();

//less ugly, but more typing, so still ugly
var $ = jQuery.jQuery;
var selection = $();
Again, ugly. It should be possible to set the module value to be a function. I know this makes some circular dependency cases harder to deal with, but as I outlined in the CommonJS trade-offs post, it is possible to still have circular dependencies. Even in CommonJS environments now, it is seen as useful. Node supports setting the exported value to a function via module.exports, and there is a more general CommonJS proposal for a module.setExports.

It means the developer that codes a circular dependency case needs to take some care, but it works. Coding a circular dependencies is a much rarer event than wanting to use a module that exports just a constructor function or function. The majority use case should not be punished to make a minority use case a little easier, particularly since you can still trigger errors in the minority use case. Coding a circular dependency will always require special care.

This particular point makes it hard for me to get on board with Simple Modules even in its basic lexical scoping/static loading form. I strongly urge any module proposal to make sure functions can be treated as the exported value. We have that capability today with existing module implementations, and it fits with JavaScript and the importance it places on functions.

Given the extra typing that would be needed to access functions that are exported as modules, I do not see the Simple Modules syntax a net win over the function-based module pattern, particularly as used in RequireJS.

Beyond Lexical Scoping

For programming in the large, what is really needed are more capabilities than what has been outlined so far for Simple Modules. However, making modules useful needs attention in these areas. This is the "99 problems" part:

Dynamic loading

Dynamic loading is harder to work out than static loading. If there is dynamic loading, it is unclear I would need static loading . The goal of modules is to allow programming in the large, and even for a smaller project, why do I need to learn two ways to load modules (static vs. dynamic), when one (dynamic) will do? Dynamic loading is also necessary to enable all the performance options we have today to load scripts in the browser.

There is a module loader strawman proposal that would tie into Simple Modules, but I understand it will not be nailed down more until the basic Simple Modules with static loading is worked out/prototyped.

Referring to other modules

It is unclear how a Module Resource Locator (MRL) is translated to a path to find a module. In CommonJS/RequireJS, an MRL looks like "some/module", and that MRL is used in require() calls to refer to other modules. require("some/module") translates the MRL string "some/module" to some path, "a/directory/that/has/some/module.js". That path is used to find and load the referenced module.

Looking at the Simple Modules examples, it looks like just plain URLs are used as the MRL, and those do not scale well for programming in the large. You will want to use a symbolic name for the MRL, and allow some environment config to map those symbolic names to paths. Otherwise it places too many constraints on how the code is stored. It may not even be a disk -- apparently CouchDB uses design docs to store modules.

I have seen some comments about using more symbolic names for MRLs in some of the notes around the proposals, so maybe it is planned.

In RequireJS, the symbolic name is also used in the module definition. However, since symbolic names can be mapped, they do not have to be the reverse DNS symbolic names, like "org/mozilla/foo". In fact it is encouraged to not use long names.

Distributing and sharing modules/module groups (packages)

This issue can be treated separately from a module spec, but it could affect how MRLs are mapped via a module loader. And this issue really is important for programming in the large. The solution may just be "use packages as outlined by CommonJS". While there are still some gray areas in the package-related specs for CommonJS, that could be a fine answer to the problem.

Performance in the browser

This is getting even further away from the basic Simple Modules spec, but a solution to this issue should be considered for any module solution. The browser needs to be able to deliver many modules at once to the browser in an efficient way. I have heard that Alexander Limi's Resource Packages proposal may be a way to solve this that may work with the Simple Modules approach.

A common loading pattern for web apps will be to load some base scripts from a Content Delivery Network (CDN), then have some domain-specific scripts to load. As long as this still works well with the bundling solution that is great. We already have tools today to help bundling, minifying and gzipping scripts. Any solution will have to be better than what we can do today. Resource Packages could be since it allows other things like images to be effectively bundled.

Summary

I do not feel like Simple Modules are an improvement over what can be done today. In particular, I feel RequireJS when used alongside JSLint is a compelling existing solution, and it works well, and fast, in the browser.

For the more immediate goals of Simple Modules:
The larger issues of module addressing and bundling/distribution are understandably hazy in this early stage of the strawman proposals, but they will need to be addressed as well as or better than existing solutions to gain traction.

I do not want to contribute stop energy around the proposals, I am just hoping to provide feedback to indicate what problems need to be solved better from my web developer viewpoint. I appreciate I could be wrong on some things too. I may be missing something grander or larger, but hopefully if that is the case, this feedback can indicate how to explain the proposals better.

July 23, 2010 10:37 PM

July 22, 2010

Instantbird

Tip for MacBook users

Instantbird 0.2 uses the multitouch feature of Macbook touchpads in conversation windows:

July 22, 2010 08:04 PM

Roland Tanglao

Without the support of the community there would be no strong mozilla

Without the support of the community there would be no strong mozilla

I think this applies to all of the Mozilla Communities. Not just Thunderbird’s communities and not just the support communities. Thanks to Ludo for taking this photo at the Mozilla Summit a few weeks ago in Whistler.

July 22, 2010 03:46 AM

July 21, 2010

Kent James

Junk management for newsgroups in Thunderbird 3

Thunderbird since version 3 has had experimental support for junk filtering in newsgroups. The feature basically works fine, but the user interface mostly fights against your attempts to use it. I’d like to give brief instructions here for anyone who wants to try it.

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.

July 21, 2010 04:14 PM

July 20, 2010

SeaMonkey

SeaMonkey 2.0.6 Security Update

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.6 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.6 Release Notes.

Note: All users of the outdated SeaMonkey 1.x, Mozilla or Netscape suites are encouraged to upgrade to SeaMonkey 2.0 by downloading it from www.seamonkey-project.org.

July 20, 2010 07:46 PM

July 19, 2010

Blake Winton

A handy zsh function (for OS X)

A co-worker of mine was having problems remembering where the makefile puts the binary for Thunderbird when you build it yourself. Now, I type in the path far too often, so I know where it is (on my computer, anyways), but since I type it in far too often, I grabbed someone's zsh function that launched Firefox, and modified it to launch Thunderbird from either the build directory or the source directory, but only on Mac OS X.

Anyways, here it is, I hope some of you find it useful.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
thunderbird() {
  local -a currdir;
  currdir=$PWD:t;
  for nm in LanikaiDebug ShredderDebug Lanikai Shredder; do
    if [ -d "./mozilla/dist/$nm.app" ]; then
      ./mozilla/dist/$nm.app/Contents/MacOS/thunderbird-bin $*
      break;
    elif [ -d "../objdir-$currdir/mozilla/dist/$nm.app" ]; then
      ../objdir-$currdir/mozilla/dist/$nm.app/Contents/MacOS/thunderbird-bin $*
      break;
    fi
  done
}

July 19, 2010 02:20 PM

July 16, 2010

Kent James

Thunderbird’s Strategic Dilemma

In a recent tb-planning post, neandr wrote:

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.

July 16, 2010 12:58 AM

July 15, 2010

Kent James

Sending a Message (Mailnews Exchange Support)

I can now send a message through Exchange server from my Thunderbird installation.

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.

July 15, 2010 09:33 PM

Ludovic Hirlimann

More crash stats from linux

If you look at mozilla's crash reported and peek at the crashes Thunderbird get, you'll see that the number of crashes is very low on Linux. That's because people use the packaged version of Thunderbird on Linux which is slightly different from the official release one (so they don't give us build symbols and disable the crash reporter). So from a QA and dev perspective we are loosing a lot of crash information , because we think we have a good Linux installed base. This is about to change, as one of the Major Linux distribution (SUSE Linux and it's sister openSUSE) are about to send us all those crashes that are happening. This won't be in the 11.3 releases per-se, but it will be from any update package that user will install from now on. Thanks Wolfir for making this happen !

July 15, 2010 08:29 AM

July 14, 2010

Mark Banner

XPCOM registration changes coming to a trunk Thunderbird near you (Add-ons take note)

As some people may have already noticed, trunk builds (currently called version 3.2a1pre) of Thunderbird have been missing for the last couple of weeks. This is because the builds were broken by the xpcom component registration changes that recently landed.

The good news is, we’ve now fixed up all the breakage (well apart from getting one set of unit tests running again) and nightly builds will be going again from today.

For add-on authors supporting trunk, if you register your components, then you need to update your registration methods. There’s some good documentation on the MDC for how to do this.

July 14, 2010 08:46 AM

July 13, 2010

Instantbird

Instantbird 0.2 released!

After months of development and a few pre-release versions, we are happy to announce that Instantbird 0.2 is now ready to be put in the hands of the general public.

Instantbird 0.2 is now available in 5 languages thanks to the great work of our translators.

If you have tried Instantbird 0.1 back in 2007 when it was first released, Instantbird 0.2 may feel like a completely different software to you. The most dramatically changed area is the conversation window (for example, new tabs and message styles), but there are notable changes in almost every window. For a list of changes, see the release notes.

Let's stop talking, so that you can discover Instantbird 0.2 now!

Instantbird logo

In the next few days, we will talk about our plans for the future, and especially Instantbird 0.3. Stay tuned!

July 13, 2010 03:10 PM

Ludovic Hirlimann

Summit 2010 roundup

Without the support of the community there would be no strong mozilla

I came back from the Mozilla 2010 summit be more like the web edition, two days ago. I'm now still fighting jet-lag but doing way better than yesterday :-). This was a awsome great meeting. I've met a bunch of very interesting people (some of which will unfortunately get spammed on some bugs) working on plenty of position at mozilla. It was nice to finally meet some of the people I've been interacting with online in the last year and a half (Hi , Wayne, rkent, Gary, Archeopteryx, Neil ....). And I ended up having a bunch of very interesting conversations with our contributors. I probably ended up spending too much time with the French contributors (that I've known through previous events like FOSDEM), playing belote contrée. I hadn't play the game for quite a while so no regrets at all. I had setup a PGP and CAcert signing meet. PGP went well as 15 people came and participated while CAcert , only some assurers (not even all of them) showed up.

I'd like to thank all the people who did a amazing job preparing and organizing the summit - it was perfect !

Ho and yes I did make a few pictures while there :

July 13, 2010 11:02 AM

July 11, 2010

SeaMonkey Trunk Tracker

2.1 Alpha 2 Roundup

So, now that the distraction has come to an end (congratulations, Spain!), back to business. SeaMonkey (and Thunderbird) trunk has been broken for the last week or so due to the XPCOM components registration changes. The tree is still closed, but it looks much better now than in the past few days. Time to add some more SeaMonkey 2.1 features!

Upcoming:
Otherwise, SeaMonkey 2.1 Alpha 2 has been released. The following is an overview of noteworthy changes contained in that release. Also have a look at the Firefox 4 Beta 1 release notes for some more platform changes.

Notable Changes: Progress:
MailNews: Address Book: Download Manager: Audio/Video: Session Store: Preferences: Linux: Mac: Certificates: Compiling: HTML5:
CSS:
General:

July 11, 2010 11:48 PM

Instantbird

Context menus

Context menus (opened with a "right click") are a common and expected part of the user interface. It can be very frustrating when they are missing, so in Instantbird 0.2 we tried to add one wherever users are likely to expect one.

In the buddy list, the context menu of contacts can be used to start a conversation (although pressing enter or double clicking is usually faster), show the conversation history, rename a contact, move the contact to a different group or remove it from the list:

Buddy context menu

The context menu is usable anywhere in the buddy list to toggle the display of offline buddies:

Buddy list context menu

A context menu was added in the account manager too. There, it proposes all the possible actions for an account. Since Instantbird 0.2, it's possible to reorder the accounts in the list (this is also possible with drag & drop using the mouse or with the keyboard using shift + the up or down arrow).

Account context menu

A context menu is available on conversation tabs, with actions related to that tab (opening it in a new window, closing it, ...) and to the conversation, like showing the history of previous conversations with the same contact.

Tab context menu

Last but not least, there's a context menu in conversation content. This is the most "contextual" context menu we have added. The proposed actions will vary depending on whether there is a selection or if the context click was done over a link.

Content context menu

When selecting some text from a conversation, a common action is to copy it to the clipboard and then paste it in a browser to use it as the query in search engine. We have included search engine items directly in the context menus to reduce the number of clicks needed for this common case.

July 11, 2010 05:04 PM

July 07, 2010

SeaMonkey

SeaMonkey 2.1 Alpha 2 Released

SeaMonkey 2.1 Alpha 2, the second preview milestone on the way to the future of Mozilla's SeaMonkey Internet suite, is now available for free download. Please note that this pre-release version is still intended for developers and testers only. As always, we appreciate any feedback you may have and encourage users to help us by filing bugs.

The new improvements of this developer preview compared to the last one include:

We welcome any and all discussions on this alpha on our newsgroups, or you can even file a bug if you find one. Be sure to check our Known Issues prior to filing bugs.

SeaMonkey 2.1 Alpha 2 is available for free download on the SeaMonkey website. Once you have downloaded and installed this release, we'd like to encourage you to get involved in discussing and reporting problems as well as further improving the product.

Thanks for testing and helping us to make SeaMonkey even better!

July 07, 2010 11:09 PM

Messaging Add-ons

Mailing List Manager

Welcome to our first release of the Mailing List Manager.

We started the Mailing List Manager add-on with a goal to help Thunderbird users find, organize, and manage messages from mailing lists. And as we’ve worked on it internally we feel like we’ve arrived at a pretty good milestone.

Now we need more help to make the mailing list manager a success. We’re looking to find issues with the current system, and answers to questions like:

This and other feedback will help us evaluate how this feature should work inside Thunderbird and if this feature should be included by default.

We’ll keep you updated with other posts right here about the Mailing List Manager as we update it, so keep checking back. If you’ve installed the add-on you’ll see the updates come as they are available.

So go read more about the Mailing List Manager, install the add-on, and make sure to watch the intro video.

July 07, 2010 10:08 PM

Roland Tanglao

SuMoMo meeting moved to 17:45, Support & QA team canceled

Due to Mozilla Summit Schedule changes SuMoMo meeting to 17:45 (from 17:15) and Support and QA meeting canceled. Meet in the lobby, look for Roland (Canadian of Filipino heritage) in an Orange hoody. Full SuMoMo meeting details on the wiki.

July 07, 2010 08:06 PM

July 05, 2010

Roland Tanglao

Mozilla Summit Meetings for SuMoMo and Support and QA

A large number of Mozilla Staff including myself and a large number of Mozilla community contributors will be in Whistler this week from Tuesday afternoon or so  to Saturday (I arrive early Tuesday afternoon and then have to leave early Thursday night). We’re going to take advantage of this to have further meetings that I alluded to in my previous post about MozillaZine.

The two meetings are:

  1. SuMoMo Non English Meeting - Proposed Time and Place: When: Wed July 7th, 17:15, meet in the lobby
  2. QA & Support working hand in hand - Proposed Time and Place: When: Wed July 7th, 17:45, meet in the lobby

The times and place of the meetings are TENTATIVE. Stay tuned to the Summit informal meeting wiki page for last minute details or email me roland AT mozillamessaging.com or rolandtanglao on irc in #moz10.

July 05, 2010 11:09 PM

Messaging Add-ons

New features through add-ons

Until recently, development of new features in Thunderbird used a development style where initial versions created by a developer and designer would “land” in the the Thunderbird nightly releases and evolve based on feedback from those users.

Experience has showed us that while nightly users are very helpful in detecting unexpected bugs that show up unexpectedly, that nightly builds are not a great way to develop new user interface features. First, people using Thunderbird nightlies aren’t always interested in that specific feature, so any raw intermediate state makes their daily email experience less pleasant; second, there’s no commonly known mechanism for feedback on a specific feature, so while we may have many users, they often don’t know how to do anything except “file a bug”, which is great for bugs, but not great for user experience feedback; finally, we can only get feedback from people who are brave enough to try out builds that are not tested, which is a very non-representative population sample!

With the Quick Filter feature, we tried something different.

Right from the start, Quick Filter started out as an optional add-on to Thunderbird which was available to anyone running Thunderbird 3.0 or better. We used blogs, bugs, and an page on the Add-ons website to publicize and solicit feedback about the release of the add-on to a much better targeted audience.  We got lots of high quality feedback quickly, were able to create new revisions quickly, and generally made much faster progress.

After incorporating much of the feedback into the add-on the Thunderbird team felt it was ready to put into Thunderbird for everyone to use.  Only then did we take on some of the tasks that are required for production software (extensive unit tests, better code documentation, etc.).  By separating the iterative, user experience-focused and feedback-gathering phase from the hardening phase, we were able to get to a highly usable, stable feature much faster.

The Quick Filter add-on is therefore the first of our “graduate” add-ons.  With this blog, we’re expanding from the process that we started with Quick Filter, and making it easier for more interested testers to get involved.

July 05, 2010 09:54 PM

James Burke

RequireJS 0.12.0 Released

RequireJS 0.12.0 is available! This release has the following enhancements:
Thanks to Alex Sexton for driving forward the order plugin. It is a great addition to the project.

July 05, 2010 05:19 AM

July 04, 2010

Andrew Sutherland

understanding where layout goes wrong with gecko reflow debug logs (Part 1)

HTML and CSS provide awesome layout potential, but harnessing that potential to do your bidding can sometimes be problematic.  I suspect all people who have written HTML documents have been in a situation where they have randomly permuted the document structure and CSS of something that should work in the hopes of evolving it into something that actually does work.  Matching wits with a black box that is invulnerable to even pirate-grade profanity is generally not a pleasant experience.

It turns out gecko has a way to let you see inside that black box.  Well, actually, multiple ways.  There’s a layout debugger (that seems broken on trunk?) that can display visual overlays for box sizes/events/reflow counts, dump info about paints/invalidations/events as they happen as well as dumping the current content tree and frames.  Even better, gecko’s frame reflow debugging mechanism will dump most of the inputs and outputs of each stage of reflow calculations as they happen.  With some comparatively minor patches[1] we can augment this information so that we can isolate reflow decisions to their origin presentation shell/associated URL and so that we know the tag name, element id, and class information on HTML nodes subjected to reflow calculations.  A reasonably sane person would want to do this if they were planning to be doing a lot of potentially complicated HTML layout work and would a) benefit from better understanding how layout actually works, b) not want to propagate layout cargo culting or its ilk from the code being replaced, c) not want to waste days of their lives later the next time this happens, d) help locate and fix layout bugs if bugs they be so that all might benefit.

Of course, with logs that effectively amount to execution traces, examining them by hand is frequently intractable unless you really know what you’re looking for or are dealing with a toy example.  My non-reduced problem case resulted in 58,107 lines, for one.  So writing a tool is a good idea, and writing it in JS using Jetpack doubly so.

In any event, the problem is I am trying to use the flexible box model to create an area of the screen that takes up as much space as possible.  In this space I want to be able to house a virtual scrolling widget so I use “overflow: hidden”.  Regrettably, when my logic goes to populate the div, the box ends up resizing itself and now the whole page wants to scroll.  Very sad.  (Things work out okay with an explicitly sized box which is why my unit tests for the virtual scrolling widget pass…)

Let’s formulate a query on the div of interest (which I will conceal) and then see what the first little bit of output is:

*** Box 24 tag:div id: classes:default-bugzilla-ui-bug-page-runBox
*** scroll 25 tag:div id: classes:default-bugzilla-ui-bug-page-runs
scroll 25 variant 1  (parent 24) first line 406
  why: GetPrefSize
  inputs: boxAvail: 0,UC
          boxLast: 0,0
          reflowAvailable: 0,UC
          reflowComputed: 0,UC
          reflowExtra: dirty v-resize
  output: prefWidth: 0
          minWidth: 0
          reflowDims: 0,0
          prefSize: 0,0
          minSize: 0,0
          maxSize: UC,UC
  parent concluded: minSize: 0,0
                    maxSize: UC,UC
                    prefSize: 2,0
scroll 25 variant 2  (parent 24) first line 406
  why: Layout
  inputs: boxAvail: 771,1684
          boxLast: 0,0
          reflowAvailable: 771,UC
          reflowComputed: 771,1684
          reflowExtra: dirty dirty-children h-resize v-resize
  output: prefSize: 0,0
          minSize: 0,0
          maxSize: UC,UC
          reflowDims: 771,1684
          layout: 2,0,771,1684
  parent concluded: minSize: 0,0
                    maxSize: UC,UC
                    prefSize: 0,0
                    layout: 0,0,773,1684

This is the general pattern we will see to the reflows.  The parent will ask it what size it wants to be and it will usually  respond with “ridiculously wide but not so tall”.  (Not in this first base case, but the next one responds with a prefsize of “1960,449″, and that’s pixels.) The parent will then perform layout and say “no, you need to be taller than you want to be”, at least until I start cramming stuff in there.

So we skim down the output to find out where things first went off the rails…

scroll 25 variant 16  (parent 24) first line 20548
  why: GetPrefSize
  inputs: boxAvail: 1960,UC
          boxLast: 771,1686
          reflowAvailable: 1960,UC
          reflowComputed: 1960,UC
          reflowExtra: dirty-children h-resize v-resize
  output: prefWidth: 1960
          minWidth: 352
          reflowDims: 1960,1755
          prefSize: 1960,1755
          minSize: 352,1755
          maxSize: UC,UC
  parent concluded: minSize: 0,0
                    maxSize: UC,UC
                    prefSize: 1962,1755
scroll 25 variant 17  (parent 24) first line 20548
  why: Layout
  inputs: boxAvail: 771,1755
          boxLast: 1960,1755
          reflowAvailable: 771,UC
          reflowComputed: 771,1755
          reflowExtra: dirty-children h-resize
  output: prefSize: 0,0
          minSize: 352,1755
          maxSize: UC,UC
          reflowDims: 771,1755
          layout: 2,0,771,1755
  parent concluded: minSize: 0,0
                    maxSize: UC,UC
                    prefSize: 0,0
                    layout: 0,0,773,1755

Okay, that looks pretty likely to be the area of concern.  The parent asked it for its ideal size, so it told it, but then the parent apparently decided to enlarge itself too.  That is not what we wanted.  We would have been cool if just the scroll #25 enlarged itself (or its block child #26 that corresponds to the same content node but which I have elided because it always says the same thing as its parent #25) since some frame needs to end up holding the overflow coordinate space.

Thus concludes part 1 of our exciting saga.  In part 2, we hopefully figure out what the problem is and how to fix it.  Lest anyone suggest the root problem is that I am completely off base and am not remotely reasonably sane for choosing this as a strategy to solve the problem… it works in chrome.  Which is not to say that my html/css is correct and firefox’s layout is wrong; it’s quite possible for layout engines to err or deal with unspecified behaviour cases in my favor, after all.  But it does make me want to understand what the layout engine is thinking and be able to do so with a minimum of effort in the future, since I doubt this is the last time I will not immediately understand the problem or that layout engines will differ in their behaviour.

For those who want to play along at home: the raw gzip’d /tmp/framedebug file (gunzip to /tmp/framedebug) that is the entirety of the trunk firefox log with debug output, the spliced output just for the one window derived from an invocation of “cfx run splice” (it will show up under the URL in /tmp/framedumps), and the output of the output of “cfx run summarize serial-12-0 summarize unique 22,24,25,26.  Those unique identifiers are deterministic but arbitrary values for the given file.  We discovered them by using the query on the CSS class using “cfx run summarize serial-12-0 summarize class wlib-wlib-virt-wlib-virt-container-root”.  The hg repo for the processing tool is here, the mozilla-central patches are: first and second.  A minor jetpack patch is also required for the command line stuff to work.

1: I was initially trying to avoid patching anything.  This didn’t work out, but it did cause the initial log file splicing logic to leverage the arena allocation scheme of presentation shells to allow us to to map frames back to their URLs.  Sadly, it turned out the arena allocation blocks requested from the upstream allocators are really small (4k or 1k) and all from the same source and so I had to instrument the allocation as well as adding debug output of the window/docshell/presshell linkages.  The output adds an unacceptable additional level of noise to the default DEBUG case; the right thing to do is likely to cause the reflow log debugging to emit the document URL before each logging outburst if it is different from the last outburst.

July 04, 2010 05:51 AM

July 03, 2010

Ludovic Hirlimann

CACert and PGP event date and time @ Mozilla Summit 2010

So I've finally picked dates and time for both the CAcert event and the PGP signing party add , these to your summit agenda. Both event will be held on July 8th 2010. Both event will have the same meeting point. The hotel lobby's front desk.

July 03, 2010 08:22 AM

June 25, 2010

Kent James

Data Persistence (Mailnews Exchange Support)

My project to provide Exchange Web Services (EWS) support to applications based on the Mozilla mailnews codebase entered a new phase this week, where I am starting to consider the issue of local persistence of data downloaded from the server. (In the previous week, I got two other things working: display of HTML emails, and updating of UNREAD status from the local app to the server).

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.

June 25, 2010 10:55 PM

Calendar

Lightning 1.0 Beta 2 Finally Released

The Calendar Project is proud to report, that (finally) the 1.0 beta2 release of Lightning has been completed and is now available via addons.mozilla.org.

About 6 months after 1.0b1, we have managed to complete 86 further bugfixes and improvements for the benefit of our users. Notable improvements for this release are:

Lightning 1.0 beta2 is available for Windows, Mac OS X (universal builds) and Linux in 35 different languages including English. Please read the release notes for Lightning 1.0 beta2 before downloading.

Thank you again to all our developers, contributors, localizers, testers, and supporters. We would not be able to do this without your assistance!

June 25, 2010 06:18 AM

June 24, 2010

Mark Banner

Thunderbird 3.1 is now available - Free!

If you haven’t already seen it, we’ve just released Thunderbird 3.1.

Go read the website for what its got in it, some nice new changes, including (but not limited to!) an improved quick filter bar, better migration assistant and the non-modal return receipt prompt.

June 24, 2010 07:30 PM

June 23, 2010

SeaMonkey

SeaMonkey 2.0.5 Security Update

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.5 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.5 Release Notes.

Note: All users of the outdated SeaMonkey 1.x, Mozilla or Netscape suites are encouraged to upgrade to SeaMonkey 2.0 by downloading it from www.seamonkey-project.org.

June 23, 2010 03:18 AM

June 21, 2010

Calendar

Lightning 1.0 Beta 2 Release Candidate 3 is available

This new release candidate contains fixes for a few locales, no further code changes. Since the Thunderbird 3.1 release is scheduled for this week, I assume this will be the final release candidate.

Candidate builds for Lightning 1.0 beta2 in 33 languages are available as of now for:

A corresponding build of the Provider for Google Calendar is also available at those locations and will be uploaded to addons.mozilla.org once the release cycle completes.

For install instructions, please see one of the earlier blog posts.

Please tell us what you think of these candidate builds and file bugs in Bugzilla as you go. The release is near, and we are glad we can finally concentrate on the next one!

June 21, 2010 07:15 AM

June 18, 2010

Mark Banner

Nightly builds for Thunderbird Linux 64-bit builds (trunk) now available

Yesterday our build team finished the initial round of work for providing Thunderbird with 64-bit nightly builds on Linux. These are being provided for trunk (3.2a1pre builds only).

As with all nightly builds, these should be considered experimental, and are based on the very latest source code. Automatic updates should be forthcoming, though I have to admit at the time of writing we haven’t verified that yet.

We’ve also set up unit test builders on the Thunderbird trunk and Thunderbird 3.0 tinderbox trees. Thunderbird 3.1 is still to come - we’ve currently got some unexplained compilation issues there.

We haven’t yet decided when we’ll start releasing 64-bit builds with releases, we’ll determine that over the next few months.

The nightlies are available in the normal place, located here.

June 18, 2010 09:25 AM

June 17, 2010

Siddharth Agarwal

Modern times

Typography on computers has improved tremendously in the last ten years. Microsoft came out with ClearType with Windows XP (spurring endless debates about whether Apple’s or Microsoft’s sub-pixel rendering technology is better), and then with an amazing set of typefaces with Windows Vista. Meanwhile, Apple’s done its own share of shipping new typefaces in OS releases. And most Linux distributions now ship the excellent DejaVu typefaces.

Thunderbird, however, hasn’t kept up at all, despite the fact that its primary job is to display text to you. On Windows, it still uses the ancient Times New Roman and Courier New fonts, even though Microsoft itself has moved on.

Thunderbird 3 on Windows 7 next to Mozilla Suite 1.0 on Windows 98: spot the difference
win98 vs win7

This is all about to change. Starting Thunderbird 3.1 beta 2, the default typefaces for emails in Unicode and Western encodings have changed from:

Windows Vista and 7

Mac OS X

Linux

These typefaces provide a fresh, modern look to Thunderbird, and make the experience of reading email that much better.

A comparison of the old and new defaults on Windows and Mac
Windows and Mac font comparison

Unfortunately, we don’t have a solution for Windows XP yet, mainly because ClearType isn’t enabled by default and neither are ClearType typefaces always available. There’s a bug on file to upgrade Windows XP users to something better than the current defaults.

Thanks to Alex Faaborg for first suggesting the idea of changing the default fonts, dmose for driving it over the line, Mossop for suggesting the defaults on Mac, and Blake and Bryan for reviewing it in time ;)

I’d also like to thank Gurpartap for allowing me access to his Mac server over VNC to take screenshots. (No thanks to Apple for making connecting to Snow Leopard Server from a non-Apple computer a PITA, though.)

Update: The Linux defaults have been reverted to whatever the system specifies.

Update 2: Patricia Clausnitzer from PC has kindly provided a Belorussian translation of this post.

June 17, 2010 09:09 PM

Calendar

Lightning 1.0 Beta 2 and Compatibility

A few people have asked me different compatibility questions around Lightning 1.0b2. I'd like to take a moment and tell you about what applications Lightning 1.0b2 will support.

What version(s) of Thunderbird will Lightning 1.0b2 support?
This version of Lightning will only support Thunderbird 3.1. To go a bit more into the technical details, Lightning 1.0b2 and Thunderbird 3.1 use the Mozilla Platform version 1.9.2. The previous versions (Lightning 1.0b1 / Thunderbird 3.0.x) use the Mozilla Platform version 1.9.1. Therefore we cannot provide a version of Lightning that is compatible with Thunderbird 3.0.x

Will Lightning 1.0b2 support Seamonkey?
As you can see in this blog post, Seamonkey does not support the Mozilla Platform version 1.9.2. Therefore, Lightning 1.0b2 cannot support Seamonkey 2.0 or 2.1. Note however, the next version of Lightning will most likely use the Mozilla 1.9.3 Platform, which means the next release (due in about 4 months) will be compatible with Seamonkey 2.1. Until then you can still use Lightning 1.0b1 together with Seamonkey 2.0.x.

Which version of the Provider for Google Calendar should I use?
Together with Lightning 1.0b2, I will release a new version of the Provider for Google Calendar. This version will be called 0.7 and will be available on addons.mozilla.org together with Lightning.

Why don't you use the latest Mozilla platform, verion 1.9.3?
The 1.9.3 platform contains the newest features and bugfixes to date, but this also means that some Mozilla components we use, as well as some UI features, have changed and require us to adapt our code. Changes in the platform can happen every day, which means it doesn't make sense to rely on it for a release. Just imagine something big changes between now and next week: this would postpone the release indefinitely, which is obviously bad. Another factor is that the newer platform has binary components that have a different interface. If we build Lightning with Mozilla 1.9.3, it won't be compatible with a Thunderbird on the Mozilla 1.9.2 platform. It makes sense to use the same Mozilla platform version that Thunderbird does, this causes the least amount of headaches.

Why are you releasing betas, and not 1.0 final?
There is a certain level of stability that people expect from such a major release such as 1.0. We have decided on a certain set of bugs that we think should be fixed before 1.0 final is released. Back when we released 1.0b1, we had a few possibilities on what we should name it. There was 0.10 (as in 0.8, 0.9, 0.10, ...), but people could think this is similarly mature as 0.1 was. There was 0.9.5, but we wanted to make clear that the Mozilla platform used has a different minor version (1.8.x vs 1.9.x). So we ended up with 1.0b1. Now we have no other choice than to continue with betas until we've fixed all the bugs we think make sense for 1.0 final.

I hope this gives a bit of insight, if you have any further questions, please comment!

June 17, 2010 08:21 AM

June 15, 2010

Raindrop Design

Alternative design?


View on Vimeo.

This is a blog post outlining a proposed alternative layout for the Raindrop inflow and conversation reader. Check out the video above (I suggest fullscreen HD) for a screencast of the proposed layout, then hit the jump for more details.

While developing and designing the current Raindrop Inflow we put a lot of focus on pulling out useful information such as links, videos, attachments, and images - all things that would create a richer reading experience in the inflow. At a certain point though I wanted to take a step back from this and really make sure that the experience of actually reading would be enhanced in Raindrop. Ease of reading was after all going to be most important part of a messaging interface.

I started out by tidying up the layout into a strict 960px grid, which was then divided into 6 columns to house the content.


full size


full size

Immediately the organizational benefits became apparent. Information became easier to find, and things were looking more consistent. I removed almost all the images from the design (apart from the Raindrop word mark), and went with a pure css approach. The design felt visually lighter, as well as the markup - no drop shadows, gradients, bevels or embosses to be found anywhere.

The grid also allowed us to implement the new full conversation reader, which I think is the biggest benefit of this design. Loading the full conversation in the second column lets us view both the inflow and the full conversation side by side, eliminating the need to navigate to a new page to view the full conversation. Big click targets that toggle the full conversation on and off make it very simple to get back to your inflow and main menu. Also coupled with keyboard navigation (J,K) this layout makes it extremely efficient to navigate through your messages.


full size

Lastly, the typography of the entire thing has been improved. The line length of messages in the inflow is around 50 characters, and the line length in the full conversation reader is roughly 80 characters at the most. According to the Elements of Typographic Style the ideal line length is 45-75 characters. The old inflow and conversation reader would have line lengths of over 100 characters, so I think this is a great improvement. Also, you might notice that the typeface has changed from Droid Sans to good old Helvetica.

June 15, 2010 06:22 PM

June 07, 2010

Joshua Cranmer

Developing new account types, Part 3: Updating folders (part 3)

This series of blog posts discusses the creation of a new account type implemented in JavaScript. Over the course of these blogs, I use the development of my Web Forums extension to explain the necessary actions in creating new account types. I hope to add a new post once every two weeks (I cannot guarantee it, though).

This blog post is a continuation of my previous two posts, which is being broken up into multiple segments to lower the amount of text one has to read in a single sitting. The current step is to actually implement the folder update.

Only new messages

Now that we know how to add messages to the database, we need to figure out how to find the downloaded messages.

It should go without saying that checking to see if you actually need to update the folder should be the first thing you probably want to do in this function. In my extension, I need to download the front page of the specific board and check the topic list to see if it matches what is stored in the database.

For now, at least, I can rely on the forum telling me about the number of replies in a thread (one less than the number of total messages), as this is shown in the thread index of a forum. What I do is grab the reply count that I've seen and subtract that from the number that is listed to get the number of new messages I need to download. Then I need only to look at the last few messages to add them to the database.

At this point, I have two main issues to worry about. First, I am working with paginated return results. That means I actually need to load multiple documents. Second, I am not getting a list of messages, but a list of threads; therefore, I need a database that is associated with threads [8].

The database I use is a simple JSON object that exists for each folder, and so far only has a mapping of threads to the reply count that I've seen; I may give it more in later iterations of this extension.

Pagination is where the trickery in implementation comes in. First, I need to look at the thread index for new messages; if I have seen all of the messages in the last thread, I can stop looking at new pages. Otherwise, I have to grab the next page and continue recursing. Note that it is possible to hit a thread that I've fully seen and still have threads I've not seen: sticky messages can be infrequently updated yet still make it first on my list of messages.

The other issue is when loading threads. The link I end up scraping is to the first page of messages for that thread, which I may already have seen. So I need to skip over pages until I find the page that first has new messages. For now, I'm doing this naïvely by actually loading each page and counting the number of posts rather than trying to deconstruct URLs and calculating where to load. I then need to look at the last set of posts, not the first set, so I calculate the start position and read forwards. Since I'm using querySelectorAll, I get an array of results, so I don't worry about having to throw out a number of iterations; I can just start in the middle when iterating.

Once all of that is implemented, we can then put everything together to make a proper implementation of updateFolder, the function we started implementing a few pages ago. The end result is that, when all is said and done, you can load up the message pane (the last column is the number of messages in the thread): The thread pane after implementation

By comparison, here is an equivalent view of the forum that I loaded this from: The equivalent forum list

Now, I wish to ask you, which user interface would you rather use to view the forum?

Some notes for implementors: be prepared to delete your msf files over and over again. I would recommend tackling the individual components in this order: first build a message, then your protocol object (I found it easier to test when the running tasks were already known to be working), and then start work on tying it all into the database. Leave issues like threading for after the basic stuff is laid out, then tackle determining which messages are new if it's not implicit in what you do (i.e., you don't have a "get new messages" query you can readily use). Pagination should be last: everything is easier to test if you only have a small number of messages you really need to test.

I apologize for the excessive length of this step; this happened to be pretty much the first step where most of the necessary technology had to be used. The next step is to actually be able to display the messages in our database, which should be shorter.

Notes

  1. Kent James and I are both working on developing new account type extensions (he doing an Exchange connector and I this blog series); both of us have identified the narrow-mindedness of the database as an issue. It is therefore possible that my workaround here will not be necessary in the next few versions.

June 07, 2010 10:42 PM

May 31, 2010

SeaMonkey Trunk Tracker

2.1 Alpha 1 Roundup

Welcome back! This update comes a lot later than I initially thought. On the upside I can present you with an more-or-less overview of changes between the last stable release and the first SeaMonkey 2.1 alpha version which has just been released two weeks ago (for the platform changes, see Firefox 3.6 and Mozilla Developer Preview (1.9.3 alpha)). Parallelly, SeaMonkey 2.0.5 is expected to be released tomorrow (Pacific time). The changes contained in the stable branch releases are part of the release notes nowadays so I will not track or repeat them here.

Since the first alpha has been cut, new features have already been pushed to the trunk, and more are to come. The SeaMonkey 2.1 Features wiki page tracks the overall progress of major new features. Short teaser of what is already available in trunk nightly builds:

Here is a list of notable SeaMonkey changes between versions 2.0 and 2.1 Alpha 1:

MailNews

Address Book

Download Manager

History

Audio/Video

Session Store

Preferences

Linux

Compiling

General

May 31, 2010 12:05 AM

May 26, 2010

David Ascher

Outlook PST importer anyone?

This week, Microsoft published an open source (Apache 2) SDK to read PST files. From what I heard, it works with Unicode PST files as generated by Outlook 2003 or later.

It’s a healthy move on Microsoft’s part, as it releases their users from feeling like their data is locked in to their relationship with Outlook. I hope the code is easy to use, etc.

I’d naturally be very interested to hear of anyone experimenting with using this code in an add-on to make the process of importing all one’s data from Outlook into Thunderbird. If you know of such an effort, let me know!

May 26, 2010 06:11 PM

May 21, 2010

Joshua Cranmer

Developing new account types, Part 3: Updating folders (part 2)

This series of blog posts discusses the creation of a new account type implemented in JavaScript. Over the course of these blogs, I use the development of my Web Forums extension to explain the necessary actions in creating new account types. I hope to add a new post once every two weeks (I cannot guarantee it, though).

This blog post is a continuation of my previous post, which is being broken up into multiple segments to lower the amount of text one has to read in a single sitting. The current step is to actually implement the folder update.

Folder updating

To actually achieve our goal of getting a correct message list, we are going to modify the implementation of updateFolder. This function is called whenever a folder is selected in the folder pane; conceptually, you can view the function as causing the cached database to be resynchronized with the actual folder. For example, this is where a local folder would actually reparse the mailbox if the database was incorrect or missing.

This function essentially consists of three steps: figure out new messages, process them (i.e., apply filters), and then announce to the world that they exist. Some account types (like IMAP) may need to do more involved message processing, but this is the general gist of what goes on [4]. I'll ignore the processing step until I start talking about filters.

Database Details Devil

To start with, I'll cover the last step. Announcing to the world that a message exist boils down to adding a new header to the database. So how do you add a new header to the database? It requires three easy steps: create the header, populate the fields, and then add it to the database. With the proper listener setup, all of the other notification is done for you automatically. But as they say, the devil is in the details.

Let me begin by explaining some things about messages. There are five different representations of the message: the message key, the message header, the message ID, the message URI, and the necko URL object. Siddharth Agarwal has a nice diagram that shows how to convert between these representations. The last two are more concerned with displaying messages; it is the first three that are interesting right now.

Message keys are the internal database key for a message; the tuple (folder, key) is guaranteed to be unique by the database. Message keys are unsigned 32-bit integers (with 0xFFFFFFFF, or -1 in 2's complement, reserved as the "no message here" key). In general, any time a property needs to refer to another message, the message key is used; as a consequence, it means that such properties cannot refer to stuff across folders.

Message IDs are the RFC 5322 identifier for a message. These identifiers are supposed to be unique (for logical messages, not in a "the message at offset 0x234f3d in this file" sense). The most important use case for message IDs is that they are a critical component for threading.

The message header object is an object of type nsIMsgDBHdr. These are objects are directly backed by the database. However, many of the properties do not notify the database of changes, so you generally do not want to actually set them. Like all generalities [5], there are exceptions to this rule. Right now, we want to manipulate headers before adding them to database, and therefore we do not want to notify people of changes to not-yet-existing headers, so we want to actually use the fields of nsIMsgDBHdr.

So, the first thing you need to do is to decide what your message key is. Message keys are going to be used to get the message URI, so it should be a property that is easy to associate with methods. IMAP uses message UIDS, local folders the offset into the mbox [6], and NNTP uses the key numbers in the group. In my case, it appears that the forum assigns each post a unique number, so that is what I'll use.

After the message key, the most important properties are the major ones for display. The author attribute correlates to the "From" header, subject to the "Subject" header, and date to the "Date" header. All of these will be used to generate values in the thread pane columns; things would look strange without these.

The other major property in the display is flags. Flags, as the name implies, is an integer where each bit corresponds to a different flag. The most important of these are probably HasRe, Flagged, and New. Flags should be set with OrFlags and AndFlags instead of manipulating the value directly. And don't set these values with the mark* methods, as these cause notifications to be fired (remember that we haven't added the message to the database yet).

If you want to do real threading, you will want to set message IDs and references [7]. The References header is a space-separated list of message ID tokens (wrapped in angle brackets), although the parser routine in the database does a pretty good job of ignoring any random crap. The list is in the reverse order of hierarchy, so the last element is the message's parent, second-to-last the grandparent, etc.

Threading is implemented in the following manner. First, the database attempts to find a message for each message ID in reverse order. If it finds one, that is made the parent header and threading stops. Otherwise, if correct threading is enabled, an attempt is to made to find a thread which has that message ID. Otherwise, if use strict threading is not enabled, a thread that has a message which has the same subject (without Re) is used as the thread. If threading without re is disabled, the message has to have the HasRe flag checked to perform the last step. Finally, if a thread could not be found by this point, a new one is created.

To combine messages in a thread, then, the References field needs to be set for the messages. If people enable correct threading (this is done by default), you can use a simple trick: create a valid message ID for each thread and stuff that as the References header.

A practical example

In my case, I have an author (without email addresses), a subject (with possible non-ASCII text but without Re: stuff), a date in a standard format, as well as a simple per-thread unique identifier for message keys. I also want to make threads—although this will only be two-level threads. Ideally, I should also be flagging the sticky threads, but I'll leave that for a later version. So what does this code look like?

_loadThread: function (document, firstMsgId) {
  let database = this._folder.getDatabase();
  let conv = Cc['@mozilla.org/messenger/mimeconverter;1']
               .getService(Ci.nsIMimeConverter);
  let subject = /* one for the thread */
  let hostname = this._folder.server.hostName;
  let charset = document.characterSet;
  /* for each new message */ {
    let postID = /* generate msg key */;
    let author = /* get author name */;
    let date = new Date(/* get text string*/);
    let msgHdr = database.CreateNewHdr(postID);
    // The | is to prevent accidental message delivery
    msgHdr.author = conv.encodeMimePartIIStr_UTF8(
      author + " <" + author + "@" + hostname + "|>", true, charset, 0, 72);
    msgHdr.subject = conv.encodeMimePartIIStr_UTF8(subject, false, charset,
      0, 72);
    // PRTime is in µs, JS date in ms
    msgHdr.date = date * 1000;
    msgHdr.Charset = charset;
    msgHdr.messageId = postID + "@" + document.documentURI;
    if (firstMsgId) {
      msgHdr.setReferences("<" + firstMsgId + ">");
      msgHdr.OrFlags(Ci.nsMsgMessageFlags.HasRe);
    } else {
      firstMsgId = msgHdr.messageId;
   }
   msgHdr.OrFlags(Ci.nsMsgMessageFlags.New);
   database.AddNewHdrToDB(msgHdr, true);
  }
}

First, we get a reference to the database. Remember we implemented this in our last step, so this shouldn't present any problems. We also get the things that are shared in this thread: the subject, hostname of the server, and the charset. For each of the posts, we collect the post ID, the author, and the date of the post as text strings, and then convert them into an integer, string, and a date respectively.

Using the CreateNewHdr function, we get a new message header that we can manipulate. Since I'm trying to be aware of non-ASCII text, I'm using the MIME encoding strings to prepare the author and subject. Remember that the MIME specifications want you to encode non-ASCII text in the headers; the function we use is the simplest way to do the encoding.

If you're not working with actual email, the from string can be contorted. What I did was to create a fictituous email that could be theoretically tied back to the author in a systematic way (for a possible future compose code that does forum private messaging). The purpose of the pipe character at the end is to prevent accidental mail delivery; I also used the hostName and not the realHostName, so this email address would be traceable even if the user changes the host name on me.

The message date I have is a formatted string; the Date constructor is pretty handy at converting most forms of these strings into a usable JS Date object. Then I have a JS Date object, which is measured in milliseconds, whereas the date attribute is a PRTime, which is measured in microseconds, so I need to multiply by 1000 to actually set the property. Ironically, the date is actually stored in seconds in database and is converted to and from microseconds on the fly.

The Charset attribute, apparently only used for search right now, is derived from the character set as reported by the DOM. This means that it is the same character set as would be assumed by the layout engine, including character set overrides.

The message ID is simpler to generate: valid URIs are pretty much valid right-hand-sides of a message ID. A post is pretty much representable as a tuple of the thread page and the path to the post in the DOM, so this message ID is also an easy way to get to the message. References are also generated as I described above; in a later version, I may try to do sniffing to figure out from quoting who is replying to whom and recreate actual threads. Note that when setting the message ID, the outer angle brackets are optional.

The last thing I set is the flags. A complete listing of flags can be found on MDC. In this case, the only flags I care about are HasRe (since I want to generate "Re:" headers) and New; most of the others will probably be set by the user in the UI.

Finally, we add the header to the database. The last parameter tells the database to tell anyone listening that we have a new message. After we have loaded all of the messages, we need to commit the database:

database.Commit(Ci.nsMsgDBCommitType.kLargeCommit);

A brief note to make here: it doesn't really matter if you do a large or session commit, they both end up doing the same thing. Small commits end up doing nothing.

Notes

  1. Like most synchronization stuff, you theoretically also have to deal with deletion on the remote side as well as read changes, etc. The more I think about it, the more I'm torn on whether or not I should implement it. For now, I'll recommend that you weigh the cost of trying to determine deleted messages versus the commonality of deletion or other modification.
  2. Except, I am told, that all words that end in -tion in French are female.
  3. Incidentally, this is a major part of the reason why there is a 4 GiB limit on mailbox size in Thunderbird and SeaMonkey.
  4. What about In-Reply-To, you may ask. This information is pretty much redundant with References, so what happens is that, for the purposes of computing threading, this header is appended to the References header. And you do this before calling on the database header.

May 21, 2010 09:47 PM

May 19, 2010

James Burke

Using RequireJS syntax in Jetpack Reboot

I have a clone of the Jetpack SDK that has support for the require() and require.def() syntax supported by RequireJS.

Right now the syntax support is very basic. It does not support these features of RequireJS:
But you can do the main things, like:

require(["dependency"], function (dependency){}());

and define modules via:

require.def("moduleName", ["dependency"], function (dependency){}());

It should also support CommonJS modules that were converted to RequireJS syntax via the conversion tool in RequireJS, but I have not tested it extensively.

The changes are just in one file in the sdk, securable-module.js. So you could just grab that file if you wanted to play with it. There is a sample app in the source if you want to see it in action. Also viewing the changeset shows the diff on the securable-module.js file as well as the example app source.

The full cloned repo is available via:

hg clone http://hg.mozilla.org/users/jrburke_gmail.com/jetpack-sdk-requirejs

Why do this? Because sharing code between the browser and other environments is hard with the regular CommonJS syntax. It does not work well in the browser. The browser-based CommonJS loaders that use eval() have a worse debugging experience. Starting with the RequireJS syntax makes it easy to transfer the modules for use in the web browser, and the RequireJS code works in Node and Rhino.

I would like to add support for RequireJS plugins in Jetpack. I can see the i18n plugin and text file plugin being useful for Jetpacks. That will likely take more work though. I want to see if the basic syntax support is useful first.

I ended up not using that much RequireJS code, just some argument conversions and supporting "setting the exported value". It relies on the existing Jetpack code for paths and package support.

May 19, 2010 09:51 PM

SeaMonkey

SeaMonkey 2.1 Alpha 1 Available

SeaMonkey 2.1 Alpha 1, a first preview of functionality in work for SeaMonkey's future is available for free download. Please note that this pre-release version is intended for developers and testers only. As always, we appreciate any feedback you may have and encourage users to help us by filing bugs.

This developer preview introduces many improvements, including:

We welcome any and all discussions on this alpha on our newsgroups, or you can even file a bug if you find one. Be sure to check our Known Issues prior to filing bugs.

SeaMonkey 2.1 Alpha 1 is available for free download on the SeaMonkey website. Once you have downloaded and installed this release, we'd like to encourage you to
get involved in discussing and reporting problems as well as further improving the product.

Thanks for testing and helping us to make SeaMonkey even better!


P.S.: A Belarusian localization of this entry is now available!

May 19, 2010 02:41 AM

May 18, 2010

Thunderbird Localization

Thunderbird 3.1 RC1 - sign-off deadline extended by 24 hours

Because some bugs didn't get fixed in time, the RC1 of Thunderbird 3.1 has been postponed by one day. Therefore We will accept sign-ins until Tuesday 18th May @ 23:59 PDT.

Please go to the l10n dashboard and sign-off for your locale once your locale has gone green.

May 18, 2010 08:58 AM

May 17, 2010

James Burke

RequireJS 0.11.0 Released

RequireJS 0.11.0 is available to download! This release has the following enhancements:
Thanks to Alex Sexton for outlining the Caja and require() renaming aspects and to Sean J. Vaughan for instigating the JSONP plugin.

The priority config option is the parallel download support I mentioned in the "A require() for jQuery" post. I now believe RequireJS meets all the requirements outlined in that post.

Some icing on the cake I want to pursue: a server-based service that can create optimization layers on the fly. I have all the pieces in place in the optimization tool to allow this, and I previously built a server build option for Dojo. With that, you could conceivably use the priority config support with a server that did the optimization layers on the fly:
require({
priority: [
"http://your.domain.com/opt?include=event,object,widget,Dialog&exclude=jquery",
"http://your.domain.com/opt?include=page1,Tabs&exclude=jquery,event,object,widget,Dialog&exclude=jquery"
]
}, ["page1"]);
Or something like that. The fun part -- this server endpoint would use server-side JavaScript, since the optimization tool in RequireJS is built in JavaScript. I could use Node or something Rhino-based. It is likely to be Rhino-based since that allows the minifier, Closure Compiler, to work on the fly, since Closure Compiler is written in Java.

That server-based service will likely take a more design work and thought, but if you feel it is something necessary for your project, please let me know. Better yet, if you want to contribute to the project in this area, leave a note on the mailing list.

May 17, 2010 04:51 AM