We're now pulling Mozilla lists (10,000 emails a month)

It's Christmas today, and while I could be playing with my new gifts (an electric toothbrush, how thoughtful!) I instead loaded the Mozilla list histories into MarkMail.

Now, don't get me wrong: I'm not saying this to complain. As a child I used to organize pennies, sorting each one into different holders based on its year and mint. My favorite modern penny was the 1973-S, a coin minted in the year of my birth year at the exotic-sounding San Francisco mint. I still have all 75 of those coins I ever found.

Looking at Mozilla, we have 100 mailing lists and a little over 270,000 historical emails. Everything from Firefox to Thunderbird to Seamonkey. Choose your favorite!

We've loaded the MySQL lists and their 360,000 emails

Some projects are small, and some are big. MySQL is big. According to MarkMail analytics, people on the various MySQL lists have exchanged over 360,000 emails since March 1999. That's a new MarkMail activity record for lists concerning a single project.


What are all these people saying? Who has time to follow along? I don't know, but I expect if you have a MySQL question, you can find an answer in MarkMail's new MySQL archive.

May I Take Your Order (By)

Almost immediately after launching MarkMail we started to get feedback. After we calmed ourselves down from the excitement of having users that care, a few things started to stand out. One of those items was the desire to order the search results by something other than relevance.

Adding basic support for this feature was done with 5 minutes of work and a few lines of code. This basic support allowed you to change the ordering by adding an order: in your query (eg: order:date-forward, order:date-backward). Being geeks that can't live without a command line, this level of support was fine for us, but we figured the population at large would appreciate the ability to change the ordering in the UI.

So after a bit of discussion we've done exactly that. There is now a drop down right above the search results that you can use to adjust how the results are ordered.


Keep that feedback coming and let us know what's important to you.

Loaded By Request: AppFuse, XWiki, and WSO2

We have a long queue of lists we plan to load, but here's a little secret. If you write in to us, we load your list sooner. It's true what they say: the squeaky wheel gets the grease.

So in the last month, by request, we've loaded a few new project lists:

• AppFuse (an open source tool for writing Java apps faster)
• XWiki (a platform for wiki apps)
• WSO2 (web services software)

Keynoting XML 2007

This week I gave the closing keynote at XML 2007 in Boston.

The opening keynote had a three-person panel debating the question, Does XML have a future on the Web? I decided with the closing keynote to bookend that topic and answer the question with a talk titled You're Darn Right XML Has a Future on the Web, using MarkMail and its XML-centric model as supporting evidence. I've posted the talk's slides as an interactive Flash file. Click to advance.


During the rest of the week I was handing out "list:xml-dev" T-shirts, just like we had for ApacheCon but with a new list community.

My favorite quote was from Jon Bosak (often called the father of XML) who, upon receiving his T-shirt and learning how MarkMail was built on XML, said to me: This is cool on so many levels.

Lack of History is History

Before we launched the site we quickly recognized how annoying it was that the browsers back button didn't work while searching and reading messages. Because the site has some Ajax goodness, we knew that getting browser history working properly would take a bit of effort so we skipped it for the launch.

However, when I saw this post on Ajaxian about the new release of Really Simple History I figured I'd play around a bit. The documentation for the library could be a bit more extensive, but because it truly is so simple to use I got things figured out in no time. Even better than being simple, its support for various browsers is fantastic.

Even though the library does a ton of the heavy lifting for you, there was thankfully some fun left for me. The library works by adding on a fragment identifier in the url (you know, that bit in the location bar after the #). Fragment identifiers are usually used to jump you to a specific part of a page. This jump doesn't cause a page refresh but fortunately it does add an item in the browsers history.

So to get things to work I had to figure out a way to encode the state of the browser into a fragment identifier. The state includes things like your current query, what page of search results you're on and what message you're reading. I ended up using a scheme similar to GET variables (key:value pairs) so that part was pretty easy.

So now I was able to add items in the browsers history, sweet! But that's only half of the story. When the user actually uses this history, it's up to us to decode the fragment identifier and properly restore the state of the browser. This turns out to be a touch tricker than it sounds. Mostly because we don't want to refresh parts of the page that don't need to be refreshed.

The site required a few other tricks to get things working, but overall the process was much easier than expected. So have some fun now that you no longer need to think so hard about that click. Thanks to Brad Neuberg and Brian Dillard for their work on Really Simple History.