John Gruber was recently featured for a second time on Dan Benjamin’s instantly-awesome Hivelogic Podcast.

I’m glad that Jesper heard and was intrigued by some of the same comments I was, because he reminded me that I wanted to comment on a subtle but worth-repeating impression that I took away.

The comments are those pertaining to the introduction of scripting language bridges as standard developer resources in Leopard OS X 10.5. Gruber points out that for developers, the presence of these scripting language bindings will both open up the platform to a wider audience of developers, and enable selective use of scripting languages where the highest performance is not necessary.

He suggests that a typical developer will write everything in Ruby or Python, and then do performance testing. Anything that needs a speed-up can be redone in Objective-C. You know, that “slow” dynamic variant of C :)

This analysis is foreboding, because it’s exactly what programmers have always done when they switched to a higher level language. 10 years ago a programmer would be more likely to “switch to assembly” for a much-needed performance boost. Has it come to this? Are we moving to a higher plane? If you’re like me, you’ve probably become quite comfortable in your Objective-C universe, and somewhat dismissive of the scripting languages as they begin to encroach on our holy ground. But we run the risk of being like those losers who still insist on programming everything in assembly, while the higher-level code would be just as fast and easier to maintain.

Is C the new assembly?

I’m working on an application that has some simple networking needs, among them fetching small bits of data off of a variety of user-configured web sites. Since the needs are so straight-forward I thought using NSURL and its “resourceDataUsingCache:” method would be the way to go. It so happens that this application already has a separate thread running when the data is needed, so the synchronous call is fine:

NSData* myWebData = [myURL resourceDataUsingCache:NO];

This works amazingly well and reliably returns the contents of the specified URL, exactly as you’d expect. Unless the server decided to zip encode the data! In this case, you’ll get back data that for all intents and purposes looks completely wacked.

The problem stems from the fact that NSURL’s data loading mechanism passes the following header to the server when requesting the URL:

Accept-Encoding: gzip, deflate

But when the server complies and returns the data, NSURL shrugs and passes it straight back to the caller, without doing us the favor of unzipping it.

Becky Willrich acknowledged the bug in NSURL a few years ago, and suggested using a lower level API to work around the problem. She also identified an insidious aspect to the bug, which is that a server won’t necessarily give you zipped data just because you offered to handle it. In fact, a server that is in the habit of giving zipped data may choose not to if there doesn’t seem to be a benefit to doing so. In particular, if the cargo is so small that it would be more trouble to zip it than to just send it.

So why am I writing about this? Mainly to publish a simple workaround to the problem, using a slightly more complicated set of classes and parameter values, but ultimately being almost as simple as the original:

NSError* theError;
NSURLResponse* theResponse;
NSURLRequest* urlRequest =
	[NSURLRequest requestWithURL:myURL
		cachePolicy:NSURLRequestReloadIgnoringCacheData
		timeoutInterval:60.0];
NSData* myWebData =
	[NSURLConnection sendSynchronousRequest:urlRequest
		returningResponse:&theResponse
		error:&theError];

Monitoring the situation with tcpdump from the command line, I see that the same zipped content is being requested and received, but evidently NSURLConnection is kind enough to perform the extra step of unzipping it for me. Whoo!

Note that the methods used require 10.2 with Safari 1.0 installed, or 10.2.7 or later.

OK … I mean this in the nicest possible way, because I have also considered (and may someday pursue!) writing my own ToDo-type application.

But I’d like to offer my revision on a popular joke from academia…

1. Those who can, do
2. Those who can’t do, write ToDo apps.
3. Those who can’t write ToDo apps … eventually figure out how to do.

Maybe this should be filed under “No Duh” but it’s taken me this long to figure out that Mail’s smart folders might actually save my life.

For the past year or so, I’ve adopted the “save everything” approach, ala gmail, except on my Mac. So I have this huge “Received Mail” archive that actually, for better or for worse, contains every single email that makes it to my inbox, including spam that SpamSieve filters.

I’m not perfect at this, but I like to strive for an empty inbox. This makes me feel less stressed. So I “delete with abandon,” knowing that a copy has been archived for future reference. Unfortunately, when I delete with abandon I sometimes lose references to mail conversations in progress. I want to go back and see exactly what somebody said a few messages back, so I’m forced to go to my mail archive and look it up.

No problem, right? Wrong. My mail archive is huge so Mail stutters and thrashes. This is because even though I only care about the message I just received a few minutes ago, it is preparing to show me the entire history of my email life.

Now for the punch line. Smart folders solves this problem! I added a “Recently Viewed” smart folder to Mail, which simply shows me any message I’ve looked at in the past 2 days. At first I tried “Recently Received” but discovered that it also showed me all of the spam I’d received. “Recently Viewed” is perfect, because it shows me stuff I’ve dredged up out of the past. It’s my Mail message working set!

I was so pleased by this that I also added a “Recently Sent” smart folder to do basically the same thing, but for messages that I’ve recently written to others. My only major complaint is that I can’t order the smart folders above my gigantic IMAP hierarchy. It’s a pain to navigate down the mailbox list to find them.