http://www.whereiwrite.org/

Photos of science fiction authors and their creative spaces.

BoyGeniusReport and Engadget (sourcing Pre Central) are both reporting that:

the Pre will, in fact have IMAP IDLE (AKA Push) Gmail capabilities,

Let’s get one thing straight: IDLE is not Push

IMAP has been around for awhile, and so has the IDLE extension. This allows you to login to your IMAP account and remained logged in while idling, and notifications of new mail are sent to the client. Note that this does not push the mail out itself, just the header, with message marked as new so the client can then download the mail when initiated by the user. I use IMAP with IDLE support on my mail server, and it is fantastic, yes, but it’s not “Push” mail. What Apple and the entire rest of the world mean when they say Push mail is that the entire message is delivered to the client instantly after the server receives it. Push requires more bandwidth, a bit more CPU usage, but most importantly a protocol that is not IMAP.

In my research there are only a small number of ways to achieve Push mail. Microsoft Exchange does it, and while I don’t know what Yahoo Mail is doing or what Apple is using for MobileMe Push, it’s more akin to what Exchange is doing at the protocol level and definitely not IMAP IDLE. There is also some Java based Push mail server implementation available from Sun, but as far as I know it is not open source, or even free of charge. To my best knowledge there is currently no open standard for pushing mail. Believe me, I’d love it if there was and I would be the first person installing “GNU FreePush” or somesuch on my personal Linux mail server if anything existed. But for now, IMAP IDLE is poor man’s Push until there is such a standard. In my crazy imagination, Apple is currently using a homebrew Push protocol and server and they’ll release the source along with Snow Leopard Server.

Rejecting all of them, consistently, would in fact be no good at all. The feeling of being part of the monolith — of being the monolith — really only surges when I use my position to act capriciously.

To act fairly would be to follow the rules. To act capriciously is to be the rules.

Damn, I love John Gruber.

I had thought that Apple’s three-pronged, open answer to Exchange was going to be IMAP+CalDAV+LDAP, but today I learned about [v]CardDAV. It’s an IETF draft spec that combines WebDAV and ACLs to create a vCard server, much in the way they are combined to create CalDAV. Major contributions to the RFC come from Apple, but as yet there’s not really any implementation available yet.

Apple is openly advertising CardDAV server on their Snow Leopard Server info page, so the commitment is real. But it remains to be seen if it will be implemented in the same open source, friendly way as Apple’s CalendarServer.

Great news, especially since LDAP sucks for shared address books.

http://www.demon.cx/icaldavmerge/

Thoughtful script from JJ Spreij to get a list of CalendarServer users and generate single, monolithic webcal feeds for the user’s entire calendar. Mine’s at webcal://calendar.airwaterunix.org

http://www.time.com/time/specials/packages/completelist/0,29569,1898610,00.html

1. Vista

7. Zune

Ouch.

But the list is suspect, because 5 is YouTube, which aside from the user comments I don’t think anyone could argue is a failure.

http://news.cnet.com/8301-13846_3-10242526-62.html

“I’m a guy who doesn’t see anything good having come from the Internet…(The Internet) created this notion that anyone can have whatever they want at any given time. It’s as if the stores on Madison Avenue were open 24 hours a day. They feel entitled. They say, ‘Give it to me now,’ and if you don’t give it to them for free, they’ll steal it.”

http://furbo.org/2009/04/30/matt-gallagher-deserves-a-medal/

There are some people who think that settings should only be in the Settings app. There are others that think they should only be within the application. I can honestly see how both groups are right, but what both sides fail to realize is that it’s often a matter of context.

If you’re working on a simple application with simple needs, relying on the infrastructure provided by the SDK is fine. You may have some additional support load for users who have problems finding your settings, but that’s a reasonable tradeoff for saving development time. Sophia Teutschler’s Groceries app is a fine example of where the built-in settings shine: I turned off the Marker Felt font several months ago, and I haven’t touched it since.

In the case of Twitterrific, there were three main reasons why we built the settings into the application:

We could not split the settings between two locations. From a user’s point-of-view, it’s incredibly confusing to have an application’s configuration in two places. This would have happened if we had put the account settings in the application and everything else in the Settings app.

Some of the settings are things that people will change on a fairly frequent basis. For example, the dark theme works best at night, while a light theme is better during the day. Leaving the app to make these types of adjustments is inconvenient.

The Settings app can’t handle preferences that are “dynamic.” An example is a vibration setting for the notification: there’s no way to make this appear on an iPhone but not on an iPod touch.

As we start to see more complex applications appearing on the App Store, I think there will be a lot of other developers coming to grips with settings in their applications

http://blog.atebits.com/2008/12/settings-are-in-the-settings-app/

Take the Weather app for example. This offers “configuration options” on the backside to manage different cities. Likewise, the Stocks app flips over to allow configuration of your stocks.

Mail on the other hand makes you manage your accounts and settings in the Settings app itself. This makes sense – you are much more likely to change what stocks you watch or what cities you’d like to check the weather for than make a new email account or change the minimum font size. The only real difference between a “setting” and a “configuration” is how often they change.

There are two problems with the way Settings work on iPhone. The first is a technical problem, the second is a developer problem. The technical problem is that third party applications cannot execute their own code in the Setting app itself. This leaves them crippled, and it’s the only reason why I didn’t include the account management features of Tweetie in Settings.

The second problem is that many developers have chosen to eschew the Settings app altogether, deciding instead to put all their settings in the app itself. In cases where where executing code is required, this is forgivable. In other cases it is not, and just sets bad precedent and teaches users the wrong way of doing things.

On iPhone, you can have one application open at a time. Compare this to the desktop where you can have an almost infinite amount of applications running at once with easy one-click focus-switching. If you keep your application’s settings in the Settings application on iPhone, your users have to go out of their way to change how something works. That means they have to quit your application, go to the Settings app (which is most likely on a different home screen page), find the application in the list (if you have 20 apps that have settings, this can be quite a chore), change a setting, quit Settings, find the application again, open it, and see if it did what you wanted. Especially if the user would like to experiment with a few preferences, that requires them to switch between your app and the Settings app a few times. Talk about inconvenient.
…
See these ×’s? This means your app is temporary. A user can delete your application whenever they so choose. The applications that come standard on the device cannot be removed and have all the settings they require in the Settings app. Your settings should be in your app, as they are just as temporary as the application itself.