The Life and Times of an Icon URI Scheme

It all began with a bug report complaining about the then dry and unvarnished FTP and file directory listing pages in Chrome [1]. The bug compared Chromium's vanilla listing pages to Firefox's respective pages; clearly Mozilla had put more effort into prettying up these pages.

Figure 1: Firefox 3.5.3 file directory listing page

Figure 2: Chrome 4.0.221.6 file directory listing page

One of the most significant shortcomings of this page was the lack of icons for files and folders. In fact, folders in Chromium's listing pages were only distinguishable from files by their trailing slash.

I decided to tackle this bug as I really like Firefox's presentation of these pages. Out of curiosity I took a look at the source code for Firefox's listing page and found out that they are using a custom URI scheme moz-icon to specify the icon images in the listing page HTML.

/**
* nsIIconURI
*
* This interface derives from nsIURI, to provide additional information
* about moz-icon URIs.
*
* What *is* a moz-icon URI you ask?  Well, it has the following syntax:
*
* moz-icon://[ |  | ]? ['?'[]]
*
*  is a legal file: URI spec.  You only need to specify a file: URI inside the icon
* if the file you want the icon for actually exists.
*
*  is any filename with an extension, e.g. "dummy.html".
* If the file you want an icon for isn't known to exist, you can omit the file URI, and just
* place a dummy file name with the extension or content type you want: moz-icon://dummy.html.
*
*  is of the format:   stock/
*
*  is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'.
* XXXcaa Should these considered platform dependent or can we share and document them?
*
* Legal parameter value pairs are listed below:
*
*   Parameter:   size
*   Values:      [ | button | toolbar | toolbarsmall | menu | dialog]
*   Description: If integer, this is the desired size in square pixels of the icon
*                Else, use the OS default for the specified keyword context.
*
*   Parameter:   state
*   Values:      [normal | disabled]
*   Description: The state of the icon.
*
*   Parameter:   contentType
*   Values:      
*   Description: The mime type we want an icon for. This is ignored by stock images.
*/

Interestingly enough, this scheme is web accessible --meaning that any web developer can use this scheme as the src for their Image objects in their HTML and JavaScript code. What's great about this scheme is that it allows developers to present platform specific icons to users. For example, <img src="moz-icon://.zip?size=16" /> would resolve the icon used by the operating system for the zip filetype.

Chromium also has a similar URI scheme for retrieving platform icons. If you look at the downloads DOM UI page, Chromium uses chrome://fileicon with a file path query to retrieve the icons for respective downloaded items. This scheme is not web accessible. The chrome:// URLs have special security privileges in Chromium that would prevent us from exposing the chrome://fileicon scheme in the manner of moz-icon. We could, of course, create a new similar scheme that would be web accessible for the use of developers and file listing pages alike.

Discussions in the Chromium-dev mailing list led to a suggestion that this "icon" URI scheme should become an open standard that every browser could implement. So I decided I would give this standardization business a shot.

The process for registering a URI scheme works as such:

1. Propose the scheme to the Public Webapps W3 mailing list [2] for feedback
2. Write a URI scheme registration template (usually contained in an Internet Draft) describing how the new scheme works. Internet Drafts must conform to the Guidelines for the Authors of Internet Drafts [3]. The registration template must conform to the Guidelines and Registration Procedures for New URI Schemes [4]
3. Send a copy of the template (or containing document) to the URI review mailing list [5] as well as any other relevant mailing list requesting a review
4. Once any review issues have been addressed, submit the document to IANA [6] specifying whether provisional or permanent registration is required.
5. If all goes well the URI will get registered and appear on the IANA registered URI schemes page [7]
6. Profit!

The entire process is structured and very iterative. Peer reviews are required to assure that the new scheme will be useful, that it is well specified and that all security risks are considered.

After this long and arduous process, I managed to get provisional registration for the Icon URI scheme [8]. W00t! You'll find it listed on the IANA URI Scheme page at least until December when it expires.

Well it's nice to have an Internet Draft for the Icon URI scheme but it would be nicer if we had an implementation of the scheme running in a modern browser.

So I wrote a prototype implementation [9] in Chromium to help move the scheme forward. Unfortunately, there were concerns that added potential security risks of this scheme outweigh the benefits. Security concerns were addressed in the draft, however it would be tricky to assure that this scheme could not be used to determine what applications a user has installed by some sort of user interaction attack. With Chromium being a security first type of browser, it would seem that the shiny new web accessible Icon URI scheme may not be the best fit. Sigh.

Well that was a whole lot of yak shaving! Didn't this start with a simple bug request for icons in file listing pages?

I plan to let the Icon URI scheme expire at the end of the year in light of Chromium not using it. It would have been a nice feature, but it was hardly a necessity. The original use case bug for this scheme can be resolved in other ways. I wrote a patch that adds icons to the Chromium file and FTP directory listing pages. There are 3 types of icons: file, folder and parent folder. The icons are hard coded as data URI into the HTML.

Figure 3: Current state of Chrome file listing page

So the Icon URI scheme was dead on arrival. The moral of this story is DON'T SHAVE YAKS!

[1] http://crbug.com/24421

[2] public-webapps@w3.org

[3] http://www.ietf.org/ietf-ftp/1id-guidelines.html

[4] http://www.rfc-editor.org/rfc/rfc4395.txt

[5] uri-review@ietf.org

[6] iana@iana.org

[7] http://www.iana.org/assignments/uri-schemes.html

[8] http://tools.ietf.org/html/draft-lafayette-icon-uri-scheme

[9] http://codereview.chromium.org/3324009

Building Android in 16 minutes!

A clean build of the "generic" Android platform on an Intel Core 2 Duo machine with 3GB of RAM running Ubuntu 9.10 32-bit generally takes around 1.5 hrs. I know this because I have built Android many many times. That's some solid sword fighting time.



Fun? Yes! Productive? Nay! I want fast Android builds! With a modest budget and an eye for speed, we should be able to significantly improve our build times. Since we are using the standard GNU make utility for our builds, we can take advantage of parallelization by running as many jobs as we have processing threads. The repo sync command, albeit network dependent, can also be parallelized with the -j flag to fetch multiple projects at once. Having enough RAM to keep everything in memory during the linking phase is helpful. Of course a faster hard drive or a solid state drive definitely helps speed up the I/O.
Luckily, I had purchased a HP Pavilion Elite HPE-150f a few months ago. The specs for this desktop are as follows:

• Intel Core i7-860 Processor (2.8 GHz, 1MB L2 + 8MB Shared L3 Cache)
• 8GB PC3-10600 DDR3 SDRAM memory (4x2048MB for ultimate performance) (expandable to 16GB)
• 1 Terabyte (TB) Serial ATA hard drive running at 7200 RPM
• Windows 7 Premium 64-bit

Hmmm... I wonder how my Android build will perform on this machine? Okay, dual boot time. So I install the latest Ubuntu 10.04 LTS (Lucid Lynx) 64-bit and grab all the required packages to build Android.

Next, I set up a buildbot for Android so we can build in style. Note that because of Android's repo tool, buildbot doesn't work out of the box; you have to code in support for repo. Okay, now that's working let's give it a shot!

And there you have it! A $1,200 CDN machine can build Android in 16 minutes! The Intel Core i7 has 8 processing threads, so the commands I used were repo sync -j9 and make -j9. Generally 1 + number of processing threads works the best when deciding how many jobs to run. Sadly the sync, being network bound, still takes ~30mins. You rarely need to do a clean sync so I can live with that.
There is one tragic consequence of these 16 minute builds: your sword fighting technique will suffer terribly. This could cost you dearly if ever you have to cross swords with d'Artagnan, Porthos, Athos or Aramis.

Sorting Photos by Filename on the iPad #fail

For a company that is known for designing great user interfaces that are pleasant and simple to use, Apple definitely made it hard for me to do something trivial. So I have a folder of image files with numerical names on my Windows PC, e.g:

00.png

01.png

02.png

...

I want to transfer them to my iPad so I can enjoy them on the go. I pull out my trusty Apple 30 pin to USB cable and connect my PC to my iPad and wait for iTunes to launch. At this point I'm thinking to myself, on my Android phone I could do all this over the air... Sigh. But let's continue... I sync my folder to the iPad and disconnect.

At this point I expected to have my photos in the logical order defined by my clever numeric nomenclature, but nay! I seem to have an arbitrary ordering of my photos. WTF?

So how do I solve this problem? ...Google... According to the plethora of Apple fanboys out there on the Internets, I should switch to a Mac and use iPhoto which has an option to sort by filename. That's great! But I'm a PC :( --Any other bright ideas?

Well, apparently, according to Apple Support (http://support.apple.com/kb/HT4221):

If your iPhone, iPad, or iPod touch is using the latest software, it sorts photos by the Date Taken tag of the photos. Specifically, your device uses the pictures' EXIF tags to determine the Date Taken information. Your device will look for the following EXIF tags within your pictures:

1. Capture Date
2. Date Time Digitized
3. Date Time Original
4. Last Modified

Okay! I'll work around the iPad's UI deficiency and modify the Date Taken of all my photos. So I fire up Windows Live Photo Gallery, select all files in that folder, change the Date taken to Aug 2nd 2010 at 11:00am. Awesome! Now I reconnect my iPad to the PC, delete the incorrectly sorted folder and resync with the newly updated folder... No dice. Same ordering as before.

Maybe it's because I changed all the modification times to the same date? Maybe iTunes caches the photos? I don't know what the issue is. I'll assume it's the former. Okay I'll resort to python now.

...code...code...code...

Here we go: sort_ipad_photos.py

#!/usr/bin/python

import datetime, time, sys, os

# iPad sorts photos by timestamp rather than by name. A solution to this is to

# change the timestamps for files so that they are sorted in the same order as

# the file names.

def get_next_time(count):

future = datetime.datetime(2010, 1, 1, 0, 0)

future += datetime.timedelta(minutes = count)

timestamp = time.mktime(future.timetuple())

return timestamp

def main():

folder = sys.argv[1]

list = os.listdir(folder)

list.sort(reverse=True)

count = 0

for file in list:

if file.lower().endswith('jpg') or file.lower().endswith('png'):

count += 1

time = get_next_time(count)

print('Changing timestamp of %s to %d' % (file, time))

os.utime(file, (time, time))

USAGE = 'Usage: python sort_ipad_photos.py folder'

if __name__ == '__main__':

if len(sys.argv) != 2:

sys.exit(USAGE)

main()

So this script will essentially change the modification and access timestamps of the files so that the first image will be the most recent one. E.g. if there are 20 images, #20 has a timestamp of Jan 01 2010 00:01 and #19 has a timestamp of Jan 01 2010 00:02. One minute increments.

This should solve my problem. I run the script and test out the ordering with `ls -t`. Looks good. I repeat the delete and sync folder to my iPad process again. No dice. Same ordering! WTF?!

The issue must be the creation date. I modified the access and modification times but not the creation date. New solution: Create new files sequentially so that their timestamps have the same order as their filenames.

...code...code...code...

#!/usr/bin/python

import time, sys, os, shutil

# iPad sorts photos by timestamp rather than by name. A solution is to

# create new files with creation dates that match the ordering of the filenames.

def create_new_files():

folder = sys.argv[1]

list = os.listdir(folder)

list.sort(reverse=True)

sorted_folder = folder + '/sorted'

if not os.path.exists(sorted_folder):

os.mkdir(sorted_folder)

count = 0

for file in list:

if file.lower().endswith('jpg') or file.lower().endswith('png'):

shutil.copyfile(file, sorted_folder + '/' + file)

time.sleep(1)

def main():

create_new_files()

USAGE = 'Usage: python sort_ipad_photos.py folder'

if __name__ == '__main__':

if len(sys.argv) == 1:

sys.exit(USAGE)

main()

Done! Okay this one actually worked! Thank you Apple for wasting 2 hours of my time!