…the single most braindamaged file format that I have ever seen in my nineteen year career”.

That bug was actually one of two times where I brushed with Mork, that time learning, and another time shortly afterwards where I learned first hand how impossible it really is to work with as part of a hack I was trying to build and later abandoned. Perhaps it was my experience at the time that just made it impossible, perhaps it really was Mork.

Coincidentally Mork is now completely dead. I suspect the last bits were actually Thunderbird who used Mork pretty extensively as Mail really is a giant database of messages, and another giant database of addresses that you interact with. I’m speculating as I haven’t been following that closely.

Long live SQLite. I still find you slightly odd at times, especially your locking which seems foreign to me, however I just think of Mork and all of a sudden, it’s OK.

The most amusing, interesting and strange comment header I’ve ever found in a script goes to mork.pl for this:

##############################################################################
#
# And Now, The Ugly Truth Laid Bare:
#
#   In Netscape Navigator 1.0 through 4.0, the history.db file was just a
#   Berkeley DBM file.  You could trivially bind to it from Perl, and
#   pull out the URLs and last-access time.  In Mozilla, this has been
#   replaced with a "Mork" database for which no tools exist.
#
#   Let me make it clear that McCusker is a complete barking lunatic.
#   This is just about the stupidest file format I've ever seen.
#
#       http://www.mozilla.org/mailnews/arch/mork/primer.txt
#       http://jwz.livejournal.com/312657.html
#       http://www.jwz.org/doc/mailsum.html
#       http://bugzilla.mozilla.org/show_bug.cgi?id=241438
#
#   In brief, let's count its sins:
#
#     - Two different numerical namespaces that overlap.
#
#     - It can't decide what kind of character-quoting syntax to use:
#       Backslash?  Hex encoding with dollar-sign?
#
#     - C++ line comments are allowed sometimes, but sometimes // is just
#       a pair of characters in a URL.
#
#     - It goes to all this serious compression effort (two different
#       string-interning hash tables) and then writes out Unicode strings
#       without using UTF-8: writes out the unpacked wchar_t characters!
#
#     - Worse, it hex-encodes each wchar_t with a 3-byte encoding,
#       meaning the file size will be 3x or 6x (depending on whether
#       whchar_t is 2 bytes or 4 bytes.)
#
#     - It masquerades as a "textual" file format when in fact it's just
#       another binary-blob file, except that it represents all its magic
#       numbers in ASCII.  It's not human-readable, it's not hand-editable,
#       so the only benefit there is to the fact that it uses short lines
#       and doesn't use binary characters is that it makes the file bigger.
#       Oh wait, my mistake, that isn't actually a benefit at all.
#
# Pure comedy.
#
##############################################################################

The title of this blog post is in no way a play on Mork & Mindy

You can also take a look at Postbox (run by some ex-mozilla folks), based the same core code with some pretty innovative features.

As a side note, a lot of my old blog posts are becoming a reality these days. I find that to be rewarding.

It supports any POP3 or IMAP account similar to Thunderbird, with options for Gmail and Yahoo Plus in the wizard (for those who don’t know what type of email account those are).

My general impression is pretty neat, but the UI needs work. It often has scroll bars to view the contents of a window (just like a webpage). This is normal in a browser, but just feels strange in what is designed to be like a client side application. Even setup has this problem.

So far I still think Thunderbird and Apple Mail provide a better desktop experience. But Zimbra’s the new kid on the block, so I wouldn’t underestimate it. It is Open Source. It will be interesting to see who contributes to it.

If anyone else tried it, I’m curious to know what you thought of it.

Vistaster n. a giant cluster-fuck; a colossal mistake; a turning point, inflection point, or event that, in retrospect, turns out to have led to the doom and demise of a once-powerful company, person or organization.

DERIVATIVES:
vistastrous. adj.
visastrously. adv.
“Have you seen Speed Racer? It’s a total vistaster.”

I think it’s about time to start using this term, so that hopefully it goes mainstream and becomes a new word.

On a related note, Festivus still isn’t in Websters Dictionary. It’s not in Thunderbird’s spell check either. That’s another word I’m lobbying for.

Adium

• Data Detectors for Adium

Dojo Foundation

• Native cryptography API for Google Gears
• Dojo-Charting improvements
• Dojo GFX Enhancement

FFmpeg

• AAC-LC Encoder
• MLP/TrueHD encoder
• Apple Lossless Encoder for FFmpeg

Gallery

• Facebook / Flickr Style Image Region Based Tagging

Inkscape

• SVG Fonts

Joomla!

• Multi-DB support, and Database abstraction layer implementation for Joomla!

The Mozilla Project

• Natural language parsing for automatic calendar event creation
• Powerful search engine for SUMO
• Support OpenID as an account login in Bugzilla
• Google Contacts Extension for Thunderbird

MySQL

• Streaming Enabled MySQL Driver for PHP
• MySQL query analyzing tool
• New in-memory storage engine
• Memcached for Query Cache

PHP

• Implement Unicode into PHP 6

Pidgin

• Master password support for pidgin

WebKit

• WebForms 2.0 Support
• Improving and Extending WebKit Inspector

WordPress

• WP-storage
• Integrated Caching Solution
• Improving the search system

I’d love to know why they decided the API route, rather than use LDAP. It can be secured using TLS, and require a bind DN and bind password. If they did it that way, most email clients would be compatible right out of the gate.

There’s also Google Calendar Sync, but only supports Outlook. Still no CalDAV.

I’m slightly disappointed, but at least with an API thinks are workable. Standards would still be best.

Open Source Compatibility. Microsoft will covenant not to sue open source developers for development and non-commercial distribution of implementations of these Open Protocols.

As far as everyones reaction to this, Arstechnica wins with the best quote:

“Instead of offering a patent license for its protocol information on the basis of licensing arrangements it knows are incompatible with the GPL—the world’s most widely used open source software license.”

It may settle some curiosity in regards to how close certain reverse engineered implementations are to the actual protocol, but beyond that I don’t think it will make any difference. I think this caveat would limit most projects ability to utilize the information. I don’t think any major project is willing to utilize code subject to that limitation.

For example I mentioned just the other day that Exchange compatibility would bring about the most corporate adoption to Mozilla Thunderbird. Well this could potentially help make that a reality, except Mozilla’s commercial arm would be subject to trouble come release time. Not to mention any downstream commercial distribution that includes it (including many Linux distributions) unless they include a version without this code.

It may however be possible for a company to sell a product and offer a GPL licensed open source “plugin” or “addon” that adds the functionality. So for example Thunderbird would ship as usual via Mozilla Messaging and various Linux distributions. If you wanted exchange compatibility you would need to go to mozilla.org and download the addon for it. Similar to the current process for the provider for Google Calendar. However this adds a nasty extra step for users. It’s far from ideal.

The other notable thing in my mind is this part of their principles:

Industry Standard Formats. Microsoft supports many data formats promulgated by standards bodies in its products today. We will apply Principle II with respect to any standards-based data formats in our high-volume products. We will incorporate customer advice from our Interoperability Executive Customer Council and our ongoing community and customer engagement efforts to give us guidance to prioritize which standards we support in any given product release.

We want OpenDocument.

So despite all the media attention, I don’t think open source gained much today. There’s potential (OpenDocument getting priority would be nice), but really no big win. I just don’t see projects giving up GPL, and I’m pretty sure this agreement would violate GPL.

David Ascher has a great post on what’s to come. There are a few things I’d like to touch on though.

…Specifically, Thunderbird 3 will build on the great base that is Thunderbird 2 (and the work already performed in trunk by the current and past contributors), and add some key features, such as:

Presumably meaning it’s based on Mozilla 1.9, though I’m not 100% clear on this.

• Integrated calendaring (building on the great work done by the Mozilla Calendar team and their Lightning add-on to Thunderbird),

Awesome. This is something that was missing from long ago. Though I wonder how far it will go without the server side being as available, robust and tested. Exchange compatibility would bring about the most corporate adoption, though that could be difficult to engineer. Google Calendar is supported via an addon. It’s still lacking in a few places, though rapidly improving. I believe it also works with Zimbra (can anyone confirm?), which is a good start.

• better search facilities,

I’m curious what this entails. Search is always tricky. Google Desktop has proven a good solution for many who need better search with their email client.

• easier configuration,

Cool. Enough said. I’ve had thoughts on that for a while.

• and a set of other user interface improvements.

Hopefully this will result in some native skinning similar to what Firefox 3.0 is doing.

Address Book is also about 4 years overdue for an overhaul. Personally I think it should be replaced entirely and use a mozStorage backend. Perhaps even look at the possibility of some data sharing with services like Facebook, Plaxo and LinkedIn. Obviously being careful to avoid causing a Scoble by scraping data. For something like this data portability will be critical.

Personally I’d like to see some standard emerge where closed messaging services can essentially be interfaced like an IMAP account. So one could plug in their account info and interact with their account via any tool they choose. Obviously sending would be limited to within the provider’s walls. Contacts, data, etc. can be sync’d between both providing a seamless experience.

…Another strength is that we already have a complete web technology stack built into our mail client, and as a result, we can consider deep integration with both websites and web services which other solutions can only dream of.

Extensions are powerful. But this is really where the strength is. It’s a rather complete platform, and constantly expanding to keep up with the latest. It’s far from a hacked together parser that does a subset of html.

I suspect 3.0 will be somewhat of a quieter release. Change won’t come overnight. Those expecting a radical new approach to email by 3.0 will likely be disappointed. 4.0 is where things will become a more disruptive. I’d assume this will correspond with Mozilla2, which might work out to be an advantage.

As a final note, for any who don’t realize Scott MacGregor and David Bienvenu (no idea where his new blog will be) aren’t working for Mozilla Messaging but will still be involved with Thunderbird. They haven’t said too much on their plans yet.

That’s about all of my thoughts on the topic for now.

Thunderbird is dead, long live Thunderbird.
Email is dead, long live Email.

I should note I do not own either device, but from what I’ve read, it doesn’t matter. Hopefully by 2nd or 3rd generation when I’m on the market Apple will have come to their senses.

The problem is that Apple hasn’t provided a good method for anyone to provide sync with the iPod. Even on older devices it wasn’t pretty, but it was workable. There is no real sync API outside of iSync, which is Mac only and not a public API. Instead what was done is mount the iPod file system and send it your data. While not awesome, this has been workable and provided many Thunderbird users with mobile data.

On the iPhone and iPod touch it’s not even possible to easily mount the filesystem. The best method I’ve heard of is hacking it so you can mount your phone using sshfs with something like FUSE. I know myself and some Linux and Mac users (horray for MacFUSE!) could manage, but I wouldn’t dare try to explain to someone how to do that. From what I’ve read the iPhone manages data using SQLite 3. Therefore it seems possible to use mozStorage to interface with it. Perhaps someone with more experience with mozStorage and db’s generated outside mozStorage would know better about any potential compatibility issues.

Calendar:
/var/root/Library/Calendar/Calendar.sqlitedb

Address BookL
/var/root/Library/AddressBook/AddressBook.sqlitedb
/var/root/Library/AddressBook/AddressBookImages.sqlitedb

Seems to me Apple could turn this into an API pretty easily by re-creating the old iPod style USB storage device mounting and give us access to these files.

In my mind the ideal implementation would be for Apple to just have a iTunes embed a mini web server locally accessible (obviously) and create a REST api to work with all data on the device. That would open up a whole new way of interacting with the device. Essentially you would interact with 127.0.0.1:[port#] and GET/POST your way through the interface. Perfect for Calendar, Address Book, Notes, or whatever else Apple comes up with.

To get a vCard for someone:

  GET /contact/vcard/?last_name=Jones HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3

vcard can also be done as xml (ooh DOM parsing for iPhone!), so there’s lots of possibilities.

To add a contact:

  POST /contact/add/ HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3
  Content-Length: 450
  Content-Type: application/x-www-form-urlencoded

  fname=John&lname=Doe&address=1%20Large%20Road...

Though it would likely make sense to go with a more vcard like naming structure.

For calendar iCalendar or vCalendar would make most sense:

 GET /calendar/ical/?start=1-1-1970&end=1-19-2038 HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3

You get the idea. Dead simple access. You could then use something likecurl to manipulate the iPhone’s address book via your existing application. It would be only accessible locally, so it’s as secure as your system. It would actually make things more secure since it would be one less reason for tinkering on the actual device, and it would open up a whole new market of iPod/iPhone software to go with all those accessories that have helped boost Apple’s market share. SyncML is cool, but SyncML is also a beast and reminds me of SOAP, WSDL etc.