Enabling spotlight search of OS X mail.app with Gmail IMAP

I've been using various flavors of OS X Mail (mail.app) with Gmail for years. The setup, particularly mapping to local folders, has had its quirks, but it's worked well for Emily. For my part I usually use Gmail directly, and, for reasons of inertia, I use an old copy of eudora/xp to archive my email on a home machine.

Recently, I tried doing a search of my Gmail respository from OS X Mail. I got almost no results. Gmail, by contrast, returned hundreds of hits.

It wasn't hard to figure out the cause of this discrepancy. The default mail.app IMAP setup doesn't actually store messages locally. It only creates a local store for messages that have been read locally, and only those may be indexed by Spotlight.

To create a searchable IMAP repository, you need to change an advanced setting ...

Mail.app Proper Set up on MaxOSX for IMAP

... Next go to Advanced, and the defaults for Enable this Account [checked], Include when automatically checking for new mail [checked], Compact mailboxes automtically [checked and greyed out], the location of the account directory, and Keep Copies of Messages for Offline Viewing [drop down menu with All messages and their attachments selected] should be fine...

I had to restart Mail.app to activate this setting. Then I let it run overnight, pulling in and indexing 45K messages. My Spotlight searches now work against this email archive.

There's still a problem with Mail.app search of Gmail files -- the Gmail tag/IMAP folder mapping means messages may be replicated between folders. (Because a Gmail message may have many tags, but an IMAP message can belong to only one folder.)

A workaround for image uploading to Microsoft’s Sharepoint Wiki.

There are some good things to say about Microsoft’s Sharepoint based Wiki.

There’s also, sadly, one very bad thing. The approach to image embedding is lousy.

Happily I have found a convoluted workaround that uses one of my favorite apps – Windows Live Writer …

1. Create a SP blog that will hold the images that will be referenced in the wiki.
2. Use Windows Live Writer to post to the wiki-image-blog. Drop your image into WLW, resize it as needed, etc. If you like, use WLW to write your image associated wiki text first draft as well.
3. After you post to the Wiki, copy and paste image and text into the Wiki editor rich text field.

This takes surprisingly little time, far less than any other option I've read of. I admit, it is convoluted!

Update 1/11/09: I've been doing this for a while now. It's bloody brilliant, even if I have to say so myself. You can take advantage of the wiki-image-blog to attach a bit of metadata, including labels, to help with image reuse. If you read this and know anyone using Sharepoint 2007, I suggest send this on to them. They'll be forever grateful.

iPhone apps - visit the best ever contest

The rankings here are much less important than the selection:

2008 Best App Ever awards voting is underway - The Unofficial Apple Weblog (TUAW)

There are very important niche products, like ePocrates, that don't show up -- but the contest has most of the apps I like. They really don't, however, have a games category for the 6-12 yo group.

Visit it to find new apps you might like.

Unfortunately nobody is doing anything important with calendars -- because there's no iPhone API for calendars.

Update 1/2/09: Probably my most valuable app is GrandDialer -- an app that speeds use of Google's GrandCentral on the iPhone. Only of use to those with GrandCentral accounts -- but a superb value.

Ed Eubanks articles on OS X task, project and data management

Ed Eubanks is one of a handful of writers who tackles the very interesting but challenging intersection of personal information management, calendaring, task and project management and "getting things done".

His most recent column for About This Particular Macintosh outlines his plans for 2009: ATPM 15.01 - Next Actions: Article Line-up and updates his long, long lists of OS X "next action" apps. His complete archive is here.

Tidbits, and especially Matt Neuberg, cover the same domain -- such as Adam's latest column on Notebook 3.0. Matt's more or less moved on to work on FaceSpan, but you can read his past columns here or via a search on Tidbits.

I'm glad Eubanks is still working this domain. The killer problem for all these apps is proprietary file formats and data lock, I'm going to ask Ed to focus more on those topics.

Blu-ray and HDTV DRM - fighting back

DRM is not entirely evil. If not for DRM, there wouldn't be computer games.

Ok, so maybe that's a bad example.

If not for DRM, we probably wouldn't have much of a movie industry left.

Unfortunately, DRM, lends itself to nasty practices that, in the end, benefit no-one. So it's one of many technologies that has a chaotic sweet spot -- a dynamic balance point that requires that no participant have overwhelming power. In other words, a bit like international affairs.

So, in the defense of the balance, an update on the anti-DRM forces (Dan's Data, emphases mine)...

Atomic I/O letters column #89

Blu-Ray movies aren't meant to be viewable in high definition without an HDCP Copy Control Crap chain all the way from the player to the display device...

... "HDCP strippers" are hardware devices that take a DRM-ed DVI or HDMI signal and turn it into an unencrypted one. As with the old "signal enhancers" that were actually bought by people who wanted to copy VHS tapes, the stripper boxes are sold as "DVI amplifiers" ...

Strippers work by using decryption keys that the content companies can just "revoke", though. If they do that, all movies released ... [jg: after] ... key revocation will become un-decryptable by that particular model of stripper. [jf: so how do DRMd players get the new keys?]

So, as with DVDs in days of yore, software anti-DRM measures are a better solution. The Blu-Ray and HD-DVD encryption scheme was completely cracked in early 2007; that made it possible to extract the device keys from any high-def disc player, and use them in some other piece of software, which can then output the decrypted data in any way it likes, including to any old computer monitor...

... SlySoft's commercial package AnyDVD HD was the first to let you play or rip Blu-Ray movies without DRM (and, eight months after the people who made the more advanced "BD+" anti-copying system declared it'd be unbreakable for the next ten years, SlySoft cracked that too...), but now there are various others...

In this battle we don't want the pirates to win, but we don't want the DRM owners to win either. Let us raise a toast to stalemate.

Google's directory of Google blogs

Google Blog Directory.

There are one or two I haven't been tracking. Time to add 'em.

iPhone: MobileMe vs. Google services

Via Macintouch, a reader compares two competing solutions, to which I add inline comments and emphases:

MobileMe

... MacInTouch Reader

Quick comparison: Google services vs Apple MobileMe

COST:
Google: free [jf: Google Apps custom domain is currently $10/year for 100 people]
MobileMe: $99/year [jf: MobileMe family pack is $93 on sale now for 5 people]

SUPPORT:
Google: web-only, no access to live staff
MobileMe: web-only, no access to live staff

RELIABILITY:
Google: pretty damn good
MobileMe: pretty damn bad

SYNC SERVICES:
Google: limited
MobileMe: dangerous

iPHONE SUPPORT:
Google: okay, iTunes sync required
[jf: Pretty bad honestly, but that's because Apple won't provide a phone API for Calendar items]
MobileMe: great when it works

WEB SITE HOSTING:
Google: Google Sites enables you to build sites with rich functionality
MobileMe: Hope you bought iLife... the web based HomePage tool is dead and gone!

PHOTO SHARING:
Google: Picassa -- fast, feature rich, and free
MobileMe: Hope you bought iLife...

VIDEO SHARING:
Google: YouTube
MobileMe: Hope you bought iLife...

My extras

CHAT SUPPORT:
Google: Flaky video on OS X
MobileMe: iChat 10.6 is good

CALENDAR SUBSCRIBE/PUBLISH
Google: Superb.
MobileMe: None

FILE SHARING/WEBDAV
Google: None except the feeble Google Apps/PDF sharing
MobileMe: Excellent.

ABILITY to INTEROPERATE with iPhone/EXCHANGE services
Google: None
MobileMe: Good in theory, I have no actual experience nor do I ever read of anyone doing thsi.

If Apple were to open up the iPhone APIs it would be a total blow-out for Google, with a nasty hit on MobileMe revenue.

Gee, I wonder when Apple will do that ...