Both are important for lowering bandwidth use. If I had to rank them, I’d say conditional GET is more importantâ€”but I find that there are lots of sites, even some very popular sites, that still don’t support conditional GET.

It looks like most (if not all) of the popular weblog hosting systems support conditional GET, which is very cool. It appears to be mainly custom content management systems used by one or just a few sites that tend not to support it. You can almost count on lack of support if the RSS or Atom feed is generated live by a script instead of being served as a static file.

(Note that I intend no disrespect for people and organizations that develop their own systemsâ€”I myself use a custom system written in PHP.)

The other day I was saying how we used to have a product named Spotlight many years ago. Here’s the graphic, which some of you may remember:

Just for jazz, here’s an even older graphic. It used to be at the top of the home page back when Ranchero was known by another name, back in ’95-’96.

Looking at this graphic, I suddenly remember that in those days image maps had to be done via a CGI on the server: there was no browser support yet. And that reminds me of the debates we used to have over whether it was okay to start using HTML tables yet, back before they were commonly supported.

The horror!

Also, in those days I was learning to write Java applets, because I thought they were the future of web interactivity. There was no such as thing as Shockwave or Flash yet. (What I particularly liked about Java was that applets could call back to the server without having to reload the page.) I never ended up doing much with Java, but I liked the language.

Update: I used Roaster as my Java IDE. I loved Roaster. Roaster ruled.

Rogue Amoeba’s Memory Cell sits â€œin your menu bar displaying the current amount of memory the foreground application is using. This is different from other memory monitors, which just display the total amount of memory used.â€

I feel like it’s Christmas. Today I’m expecting the FedEx guy to bring me 512MB RAM for my development machine.

Here’s the sad tale...

When Xcode was new, I gave it a bunch of slack because it was new. I figured that the performance problems would get fixed.

But Xcode isn’t new anymore, and I’m still seeing performance problems. Just the other day it finally occurred to me that it’s time to figure out what’s going on. No more slack.

The performance problems were pretty simple: over time, the UI would get more and more sluggish, to the point where things like closing a window might take ten seconds. Debugging was sometimes nearly impossible, as it would often time out before retrieving variable data, and each single-step might take 30 seconds. (I’m guessing on the times. It felt like 30 seconds, but it might have been less. Or more.)

I ended up quitting and restarting Xcode several times a day, just to reverse the sluggishness.

I found that this wasn’t true when I was working on a small project—it was perfectly snappy then—but NetNewsWire isn’t a small project.

So—finally, sheesh—I ran top to see what was going on. It turned out that the sluggishness was a result of not having enough memory. Well, that’s easy to fix!

My development machine already has 512MB, so this will double it. It’s a dual-processor 867Mhz G4. Not the speediest kid on the block, but plenty fast enough—as long as it’s not running out of memory.

A related subject is the subject of build times. I mentioned that NetNewsWire isn’t a small project, and it’s not, but NetNewsWire 2.0’s main project is smaller than that of NetNewsWire 1.0.8—even though we’ve been adding a bunch of features.

One of the ways we achieved that was to move a bunch of things into separate, loadable bundles. As a small example, think of the Bandwidth Stats window. Its code is fairly stable, and it’s not something everybody uses every time they launch NetNewsWire, so we took it out of the main NetNewsWire project and created a separate project that builds a bundle—a kind of plugin—that NetNewsWire loads only when needed.

If you do this enough, you can end up with a smaller project that’s faster to build—even if you’re also adding features at the same time.

Users benefit too, because your app loads only what’s essential at startup, and loads less-used things only if and when needed.

(A side effect of this is that some day, if there’s interest, we may formalize NetNewsWire’s internal plugin API and make it so other developers can write plugins that add windows to NetNewsWire.)

One implication of Spotlight’s file-centricity is that its ability to search “email” might not apply to clients other than Apple Mail — it’s the fact that the new Tiger version of Mail stores each message as a separate file that allows Spotlight to effectively return individual mail messages as search results. No other major mail client uses a one-message-per-file storage format.

I haven’t looked into Spotlight in any depth (and, if I had, I couldn’t talk about it). But, if it’s true that Spotlight only looks at files, then this creates an interesting dilemma for all the developers whose apps don’t use individual files.

NetNewsWire, for instance, does not use a separate file for each individual news item. And NetNewsWire isn’t alone, of course—in fact, I think there’s a trend toward more and more apps like this, apps that store chunks smaller than most web pages and files. (What Anil Dash calls a Microcontent Client.)

And now for some trivia...

Little-known fact—years ago, back in 1996 (I think), Ranchero Software had a product named Spotlight. It was a search engine for websites: it used Frontier (which was freeware then) and Filemaker Pro and ran behind WebSTAR and similar HTTP servers.

Spotlight cost $99, and it didn’t have the success that, say, NetNewsWire has—but we did get an “It Shipped!” plaque from Apple, signed by Heidi Roizen. (I think. My memory may not be completely accurate on some details.)

Which is to say nothing in particular, except that the name Spotlight is pretty good for search technology. (And I highly doubt that we were the first ones to use it.)

At the time our company may still have been known as World Wide Power & Light. (Another piece of trivia.) We stopped using that name because it was way too long and because someone else was using it too. (Oops.) (We had a weird domain name: wrldpwr.com. One of those domain names that takes a half-hour to explain out loud.)

If you’re an OS X developer, no matter how small, I encourage you to enter the contest. It was a great thing for us (NetNewsWire won last year in the first contest)—and it would have been a good learning experience even had we not won, since in entering we had to write about our application succinctly and describe why anyone would be interested in it. (Which is a valuable thing to be able to do.)

I’ll be attending the conference, and I look forward to congratulating the winners—which could be you!

Say you’re reading a weblog in your browser, and you want to subscribe to its feed. So you click on the XML button, or the Syndicate this Site link, or whatever it is.

You’re expecting the standard page of gibberish, so you can get the URL of the feed and subscribe to it.

But no! The feed downloads to disk instead, and the URL in the browser’s address bar remains the URL of the page you’re reading.

So how do you subscribe? You don’t have the URL. Well, depending on the feedreader you’re using, you may be able to drag-and-drop, but that’s probably a pain since your browser is actually in front.

Depending on your feedreader, you might be able to rely on auto-discovery and subscribe using the URL of the page you’re reading. But that may or may not work.

What’s happening is that the server is doing the right thing: it’s telling your browser that the MIME type of the file is that of a syndication file. (application/rdf+xml, for instance.) Your browser doesn’t know how to display it, so it downloads it to disk.

You could, in theory, tell your feedreader to handle that particular MIME type—but that won’t solve the problem, because the feedreader would get a file, but what it wants is the URL of the feed, not the contents of the feed. (You subscribe to a URL, not to the one-time contents of a feed.)

All I’m saying is that I don’t know what would be best here. It’s broken in so many ways. (Expecting a page of gibberish is itself a totally broken idea, but it does allow me to get the URL of the feed.)

One possibility—on Macs only—is that Safari’s incorporation of RSS features will make this work. You’d click on the feed, and it would appear either in Safari or in another feedreader, depending on how you have things configured. That outcome would be totally cool with me, except that it doesn’t solve the problem for users of other browsers and other operating systems.

If you’re a long-time Mac user, you remember when Mac apps tended to use multiple windows rather than multiple panes in a single window.

Think of Eudora: years ago there was no preview-in-window for messages. Each mailbox was a separate window, and each message opened in a separate window.

NewsWatcher is another example. The subscriptions were in one window, the full group list was another window, and each post appeared in its own window.

So today I got, for the first time (I think), a feature request to make it so you can optionally split NetNewsWire’s main window into separate windows, as in the good old days. I was instantly nostalgic, and I thought: yes, totally, I have to do this.

But then a second later I changed my mind. My personal nostalgia plus one feature request obviously doesn’t warrant the effort.

It got me thinking, though—why is the current approach better than the old approach?

Answer: I don’t know that the current single-window approach is better, but it’s better for 2004, and that’s what makes the difference.

The main issue is that people’s user interface expectations are radically different than they were ten years ago because of the web. People have been tuned by years of website UI to expect the following:

1. There will be just one main window. Other windows are popups that do one small thing and then, usually, disappear.

2. All their choices will be visible in the main window.

3. The UI gestures available are limited to those that can be coded in web pages.

These expectations have some consequences for application UI design:

1. You need a main window with multiple panes instead of multiple windows. (Obviously this has to be modified for document-based applications.)

2. Toolbars should exist inside the window, at the top, rather than outside the window.

3. People don’t look at the main menu anymore, since they’re used to the menu belonging to the browser rather than the web-based application they’re using. So you need enough toolbars and widgets in the main window to make your app usable. When working on your design, you need at some point to pretend your application has no menus at all.

4. Few people will think to use drag-and-drop, since it’s so rarely supported in web pages. It’s important to support other ways of moving objects. (Within limits. OS X users are used to drag-and-drop within standard table and outline views, since they’ve used iTunes and similar apps.)

Cocoa very much encourages this sort of user interface. For instance, toolbars appear at the top of windows; you can’t have them appear elsewhere without going to some trouble. Creating split views for multiple panes is so easy it’s almost silly. And so on.

(It may be that Carbon encourages the same kind of design. If so, I wouldn’t be surprised, it’s just that I’m not so up-to-date with Carbon these days so I don’t know.)

Anyway... my point is that the web has had a major impact on the design of desktop applications. And it appears that the designers of application frameworks took this into account, to the benefit of developers and users.

(Hat tip: Alex King was the first person to explain this to me succinctly. I understood the new UI conventions without having thought about why they came to be.)

Speaking of RSS TV... one of the topics at the BoF was the possibility that, in the future, syndication won’t be mainly about text. Text will be replaced by audio and video.

I didn’t say it, but I remember thinking, that if this happens then we’ll have to create something new that’s mostly text-based. The thing is, I like syndication because I love to read, and it’s the only way I can get enough new stuff to read quickly enough. Video is way too slow. Text is exactly as fast as your brain.

Of course we still plan to add support for enclosures and so on in NetNewsWire. I’m not anti-video. I’m just saying that if RSS becomes mostly audio/video and little or no text then it’s time to come up with something new that emphasizes text.

After listening to all the feedback (here and elsewhere) on this issue, we’ve decided to support Jaguar in NetNewsWire 2.0.

Jaguar was the first really good OS X release, and we’d support it forever if we could, but some day we’ll have to drop it. Not yet, though.

In case you’re curious, here’s why we decided to continue to support Jaguar:

1. We can provide the Panther-only features we want to provide without dropping Jaguar support.

The main thing is searching. SearchKit is part of Panther but not part of Jaguar, so Jaguar users just won’t get this feature, but Panther users will.

2. It would be more work at this point to switch over to Panther-only than to stick with Jaguar compatibility.

To switch over to using things like Cocoa bindings—which make our life easier but don’t provide new features to users—would mean more work. At some point, yes, we’ll make the switch, but only when there are other compelling reasons to drop Jaguar support.

At every WWDC, with each OS upgrade, Apple offers two new types of features to developers.

I’ll use last year’s WWDC as an example (since I can’t talk about this year’s WWDC).

One one hand there are features like SearchKit, which make it easy to add searching to your application. This is an example of an on-the-side feature. You can add it to your application, but it doesn’t affect much of the main body of your code. It doesn’t fundamentally change how you write Cocoa apps.

The best thing about features like this is that I can use them and just have them not show up if you’re using an older OS (Jaguar).

On the other hand there are new features that change how you write apps. Cocoa bindings is an example. This technology allows you to do delete a bunch of user interface code: it makes it easier to bind your user interface to your data and preferences. But this technology goes to the heart of your application. There’s no putting it on the side (as with searching).

So at WWDC I found myself looking at each feature and figuring out if it’s an on-the-side or in-the-heart-of-the-app feature. While I’m grateful for all the cool on-the-side features I can use, I look at the in-the-heart features and dream about them. Someday...

The common wisdom is that you support the current operating system minus one. Right now that means Panther and Jaguar. When Tiger ships, it will be Tiger and Panther.

But what that means is that two years after learning about Cocoa bindings I’d finally be able to use the technology.

So what I wonder is, is the common wisdom wrong? Given all the major new technologies in each OS release, would another rule—a six-month rule, perhaps—make more sense? (Support the current OS plus whatever was current six months ago.)

The obvious benefit is better software. The drawback is that there are people still using operating systems more than six months old.

With every WWDC, Apple announces more and more cool stuff for developers that make writing apps ever easier.

So that makes me wonder about the process of deciding what apps to develop. Assuming you have a ton of good ideas for apps, there are two basic ways to approach the decision:

1. Pick one that should be easy to implement because Apple has already given you most of what you need.

2. Pick one that should be difficult to implement because you have to invent a bunch of stuff from scratch.

For instance... when NetNewsWire 1.0 shipped, there was no WebKit for displaying HTML. There was an XML parser, but there was no object-oriented, easy-to-use Cocoa XML parser. The Cocoa bindings technology didn’t exist. HTTP networking was poorly supported. The XML-RPC support (for weblog editing) was so crashy at the time that I had to write my own XML-RPC client.

(When I was a boy, we used to have walk ten miles through the snow before we could retain an object. If we wanted to use autorelease we had to go without lunch.)

You can’t draw a conclusion from one example, but I’ll give it a try anyway. The conclusion might be that #2—pick something difficult to implement—is the better choice.

I say that because it gives you a chance to be first at something, to do something new. If it’s a good idea and you’ve done a good job, your chances of success are good.

On the other hand, you could probably do three easy apps in the time it takes to do one difficult app. So there’s definitely that to consider.

However, while I can’t talk about most of what happens at WWDC, I can tell you it’s utterly predictable that, in six months or less, there will be 15 apps that do X, 20 that do Y, and 30 that do Z—just because X, Y, and Z have been made so darn easy to do. But those aren’t apps, they’re statistics.