inessential by Brent Simmons

May 2004

Sheila Writes from Romania

My wife Sheila writes from an Internet café in the southern Carpathians...

(Now there’s a sentence I never expected to type!)


Sam Ruby: Détente. Cool.

Unique IDs

As an aggregator developer, my main mission in life often seems to be to get people to use unique IDs in their feeds. RSS 1.0, RSS 2.0, and Atom all have the concept of unique IDs—it’s just that not everybody uses them.

Unique IDs make life better for users. Here’s why:

Consider what happens when your feedreader reads a feed. It has to compare the new version of the feed with what it has already read. It has to determine, for each item in the new version, if it’s new, old, or updated.

If you have unique IDs, you can tell that an item is an updated version of a previous item. The title, description, link, permalink, and so on may all have changed—but you know it’s the same item, and you can do whatever you do with updated items.

Otherwise the feedreader has to guess. I imagine every feedreader does it differently. As an example, a feedreader might say—well, the title is the same, the body is different, but the link is the same, so it’s probably an updated item. The thing is, that’s not necessarily true, it’s just a guess. Which means the feedreader might do the wrong thing with it. And when the feedreader does the wrong thing, users don’t get the functionality they’re expecting.

If you have unique IDs, then the feedreader can be sure it’s doing the right thing, and everything works the way users expect.

Dave Winer has often evangelized guids in RSS 2.0. And it pleases me that Mark Pilgrim wrote How to make a good ID in Atom. (Unique IDs are mandatory in Atom. Good!)

Feedreader compatibility

Consider also the problem of exchanging data between feedreaders. Say you want to synch between your desktop reader and an on-line service, or between two desktop readers. How do they tell each other what items have been read?

One way would be to include the entire contents of each read item, and say, “These have all been read.” But that could be a ton of data, and you still have the problem of guessing.

It would be so much better to just pass a list of unique IDs of read items. Imagine the bandwidth savings. And feedreaders wouldn’t have to make guesses.

So unique IDs aren’t just about detecting read vs. unread items, they’re also a key to compatibility among feedreaders, which benefits users.

Bug-tracker spam

I got my first bug-tracker spam today. It was just a matter of time, I suppose. (And there was a fresh round of comments spam today.)

Spammers are the thugs of the Internet.

I’m constantly amazed by just how bad some people are. Maybe it’s because I’m getting farther and farther away from my school years, when every day I interacted with a wide variety of people. It doesn’t surprise a 12-year-old when people suck. But me, I’m surprised.

Spammers aren’t on the same level as torturers or even purse-stealers. But I think that, given a different context, they’d be happy to toss some books in a bonfire in the city square.

Update: More about Net thugs... but with a happier conclusion. See Zeldman on the Andy Kaufman effect.

CMS Collegiality

Found in my referers, an interesting post from Henri Bergius: CMS Collegiality - A Practical Approach. It’s about how open-source content management systems could work together.


I’m home alone (Sheila is traveling in Romania with family), and I’m not used to being home alone.

It’s been a week, and I’ve started to develop weird habits. Here’s how dinner works: I make spaghetti, eat left-overs for a few days, panic over what to have for dinner, make spaghetti, then eat left-overs for a few days.

It’s a really good thing I like spaghetti.

Interview with me

There’s an interview with me at The RSS Weblog.

Interviews make me a little nervous. It’s hard to know if you’re coming across as a freak or not.

One thing I like about interviewers is that they’re smart enough to not use some of the stuff I send them. For instance, Harold asked me for some biographical data, and I wrote the following (which he wisely didn’t use):

I once tried to catch a frisbee in my mouth and got a bloody lip. Another time a crow dropped a partially-eaten english muffin through the sun-roof of a car (I was in the back seat) and the muffin stuck, butter-side, to my shirt, right above my heart.

“RSS Router”

Steve Gillmor has mentioned to me a few times his idea of an “RSS Router.” (No disrespect to Atom intended: I believe the phrase pre-dates Atom. Plus the alliteration is cool.)

The idea as I understand it is this: your feedreader, like your browser and email app, is a hub of information. It makes sense to want to route information from the hub to other applications. You might want to store something in a database, send an email based on a news item, send a news item into an iChat session, and so on. Sending a news item to a weblog editor is just the first, most obvious application.

Unfortunately, browsers and email applications have rarely understood that they’re hubs and that it’s natural to want to route information to other applications. (Some have understood that, actually, but they’re the exceptions: I’m speaking generally.)

But with feedreaders we have a chance to make our applications truly routers instead of places where data goes to die. This is especially important as more and more types of information are being syndicated, and as people are relying more and more on the technology.

So, I could have called the weblog editor interface the “RSS Router Interface.” Even though I didn’t, the point is, I hope, made.

Now, it’s not magic. For it to work, receiving applications have to implement their side of the interface. From people I’ve heard from so far, it’s actually a piece of cake, which is good, as it should be. (It shouldn’t be too difficult for feedreaders, too, but it’s a little more complicated. Which is fine: there are more potential receiving apps than feedreaders.)

External Weblog Editor Interface

I put up a page documenting the external weblog editor interface that NetNewsWire 2.0 will use to send posts to a weblog editor.

One of the things you’ll note is that it’s an Apple events interface. The reason for using Apple events is that this gives us the widest possible base of implementations: Apple events support appears in Cocoa, Carbon, and a whole bunch of scripting languages. The intent is to be inclusive.

Another thing you’ll note is that it should work with apps other than weblog editors—you might want to send news items to a database or outliner, for instance, and I hope developers of such apps will implement the interface.

Email me with any questions.

I put no clauses or conditions in the documentation. (You knew I wouldn’t, right?) Everybody is free to implement either or both sides of the interface. (A note of thanks wouldn’t hurt—I’m easy to please!)

I’m aware that, if you’re writing an app that implements the receiving side, there’s no sending apps to test with yet. We’re working to remedy that situation. But if you’re writing a sending app, you can test it with the latest version of ecto, which has already implemented the receiving side.

Userland and Freshly Squeezed Software

I was totally pleased today to have two different newsreader authors contact me about the external weblog editor interface.

Scott Young of UserLand Software writes: “Interop between applications is always a good thing. UserLand would be interested in supporting this effort in Radio.”

Erik Barzeski of Freshly Squeezed Software writes: “As a blog aggregator without a blog editor, we believe strongly in working with other applications to achieve tremendous functionality... Working together is a good thing that benefits everyone, and we’re there.”

I’m not sure yet if I’ll just send them email with details, or publish a page first—either way, I will get around to publicly documenting the interface at some point. (It just takes time is all.)

At the same time, I’ve been emailing more with Phil Ulrich, Michael McCracken, and Daniel Berlinger today about supporting this interface in their weblog editors. And, while no promises can be made yet, things are moving along. (My offer still stands for other weblog editor developers that I may have missed. Send me email.)

NetNewsWire and External Weblog Editors

ecto rules, and Adriaan Tijsseling is a cool cat. Adriaan writes:

With the forthcoming NetNewsWire 2.0 release, you can now set ecto as the external blog editor. You'd be reading a cool feed in NetNewsWire, select a command, and - whoosh - the feed item's link and contents appear in a new entry in ecto. Like it? I sure do.

Here’s the story...

About a year ago (at last year’s WWDC) I first mentioned to Phil Ulrich—another good guy, and developer of a weblog editor named Userspace—that I planned to make it so that NetNewsWire would work with external weblog editor apps.

I told him that in NetNewsWire you’d be able to set a pref for which weblog editor app you use, and then whenever you choose Post to Weblog it would send that post to your preferred weblog editor.

And now we’re making that happen in NetNewsWire 2.0.

A few days ago I got email from Adriaan asking if there are any ways we could work together. I replied with an emphatic yes, because I had done support for external weblog editors in NetNewsWire, but I hadn’t yet talked to Adriaan or other weblog editor developers about it yet. (Other than that mention to Phil last year.)

So I gave him the scoop on all this and sent him some code—and, practically before I could blink, he added support to ecto and released a new version.

Today I sent email to some other weblog editor developers: Phil Ulrich (Userspace), Fraser Speirs (Xjournal), and Michael McCracken (Blapp). I like all these guys: I’ve met and/or emailed with each of them in the past, and I hope they all add the same support to their apps.

(If there are any OS X weblog editor developers I’m overlooking, please send me email. It’s my intention to be inclusive.)

But what about Ranchero’s weblog editor?

Good question. Our weblog editor is getting a complete re-do. We think, frankly, that it’s going to totally rock. (We have to think that, or else why do it all?) So we’re also in competition with other weblog editor developers.

My philosophy is that, by working together on things like this, we can show that weblog editor software has grown up, and that the main priority for each and every one of us is our users. And, if I’m right, the market for this software will grow, benefitting us all. (The number of people who would benefit from a weblog editor is huge compared to the number of people using a weblog editor.)

In the end, each person will choose the software that fits them best. For each person, it might be our weblog editor, but it might it be ecto, Userspace, Blapp, or Xjournal—and that’s cool, that’s as it should be. (Again, if I’m forgetting somebody’s product, please email me.)

What about other feedreaders?

Another good question. On a practical level, there’s no way I could prevent other feedreaders from including the same support for external weblog editors. This is one of the things I was thinking about when I wrote my Collegiality Clause post the other day.

I will publicly document this interface, sometime near when we ship NetNewsWire 2.0. Other feedreaders will be free to use it too.

Can I realistically impose a collegiality clause on this documentation? No, not really.

So here’s my pitch to other feedreader developers...

I’ve been a programmer for 24 years. I have a lot of good ideas for things like what I’ve talked about today. (There’s more to come, in other words.) If, instead of sniping, we concentrate on benefitting the people who use our applications by working together on compatibility, we can go a lot further in developing a larger market. (It’s the old rising-tide-raises-all-boats argument, in other words.)


I just heard from Fraser Speirs that Xjournal will be on board with this. I’m so pleased. Good deal. Thanks, Fraser.

Brain glitch

It’s the oddest thing—I’m sitting here working, and I keep thinking there’s a new episode of the X-Files on tonight. There isn’t, of course, but I keep looking forward to it.

And then I wonder if I can run my brain in the debugger and see what’s calling the look-forward-to-X-Files routine.

Frontier and Forking

It’s become obvious to me (and, I think, to folks like Jim Roepcke) that Frontier has at least two main areas of interest, reflecting its dual heritage.

On one hand, there are fogeys like me who would love a desktop scripting system that totally embraces OS X. We look back at Frontier of ten years ago and say, hey, we want that, only better and updated for 2004.

On the other hand, there are folks using Radio UserLand and running Manila servers that would like improvements to the server and content management features.

(There may be other areas of interest, but these are the ones I’ve identified so far.)

The fogeys (generally speaking) care about an updated user interface, support for more languages, support for scripting more applications (system.verbs.apps.iTunes?), and so on. The idea is a desktop tool that makes it easier to get more work done.

But folks using Radio and Manila care about scalability, running as a daemon, a Linux port, separating the UI from the server, and so on. Those are all valid and important issues.

As a fogey, I don’t even care that it runs on Windows. But if you’re running a Manila server on Win2K, you very much care, quite rightly, that it runs on Windows. As a fogey, I care more about syntax coloring in the script editor than I care about extending the upper limit of database file size. But if you run a Manila server your priorities are the reverse.

That’s just to say that this could potentially be a serious challenge to whoever manages the kernel. There could be pressure to fork it, more so than most other applications, because of the two strongly different directions it could go in.

What approach might the maintainers take?

One possibility is something like Mozilla-like. With Mozilla, there is a base on which different applications are created. Some of those applications (Firefox) are cross-platform, and others (Camino) are not.

This makes sense to me, because it allows the deep under-the-hood parts (the script evaluator, the object database, etc.) to be shared between these hypothetical different versions of the app.

What I would not like to see happen is a complete fork, where folks with different visions take it in different directions without coordination or sharing.

There are so many things I don’t know. Will there be a community of people that want to work on the app? How many fogeys are there, really? (Maybe we’re grossly outnumbered.) What license will be used? Will there be any kind of formal or informal organization charged with maintaining the kernel? If so, what will be their priorities, and how open will they be to different visions?

As I’ve repeated before, I don’t plan to work on the kernel, fun as it would be, since I’m so busy with my own software—but I like thinking and writing about this story, since it could be the birth of a really great open source project, and it has some interesting and unique dimensions. I’m fascinated by it.

Frontier Dreams

In the back of my mind I’ve been thinking about the open-sourcing of the Frontier kernel, and like some other folks it’s made me dream of software that’s close in spirit to the early versions of Frontier, before it became the basis for a content management system.

For those who don’t know, Frontier began life as a scripting system for Macintosh. But not just another language—it included an object database and a relatively rich (for the time) library of verbs. You wrote code in an outliner, which I still think is a wonderful way to write code.

You used it do many of the same things people use Perl and Python (and so on) for today, only it was on Macintosh System 7. Instead of using pipes and Unix-y things for inter-application communication, it used Apple events. (Like AppleScript.) It was very common to use Frontier to do tasks that required scripting one or more other applications.

For instance, your script might grab data from a Filemaker database, format it as text in Frontier, then create a new email message in Eudora and send it. With Frontier’s scheduler, its cron-equivalent, you could make this happen once an hour or whatever. And you might archive the data in its object database and create weekly reports based on that data.

That’s just a for-instance, of course. The gist of it was that it made it possible to do custom things that apps like Filemaker and Eudora would never (quite rightly) have supported on their own.

Sounds like AppleScript, right? Well, yes. But Frontier brought some things that AppleScript doesn’t have. (The browse-able object database, the richer library of verbs, the code outliner, the scheduler, and so on. Frontier is an entire environment on its own, though an open one, aware of the rest of the system.)

My dream app

First thing—I don’t have plans to work on Frontier. I’d love to use the results of someone else’s work, though! As much fun as it would be for me to work on it (partly because the kernel is an old friend, but more so because I know a lot of Frontier users who are cool cats) it just isn’t on my path. However, I’d be happy to make sure my software works well with people who want to script it with Frontier.

Anyway... my dream app goes back to that earlier vision of Frontier. To bring it up-to-date, there are a few things I’d love to see:


Whitespace-aware Python just begs to be written in an outliner. The language is similar in style to UserTalk (Frontier’s scripting language), but, key fact, it’s object-oriented.

The object-oriented thing is a big deal: I’ve gotten so I won’t even consider writing in a procedural language for anything but the smallest of tasks. I want objects.

And Python is just plain cool.

I wouldn’t advocate dropping UserTalk, I’d argue for making Python a first-class peer of UserTalk. There are some challenges to consider, though. Frontier internally is receptive to other languages. (Note that you can write scripts in any OSA language, including AppleScript). But you’d have to make it so Python could access the object database (to store and retrieve data and to call other scripts) and you’d want a way to freeze-dry Python objects in the database.

Cocoa front-end

Okay, obviously I don’t care about classic Mac OS or Windows. I care about OS X.

When Frontier was written, there were no system-supplied user interface controls for tables, outlines, and toolbars. And all applications polled for events (via WaitNextEvent, if I remember correctly).

The first obvious thing to do is replace a bunch of the user interface code with .nib files and standard Cocoa widgets. However, I think I’d retain the existing outliner for writing scripts. (Cocoa and Carbon can co-exist: it’s not a problem.) But all toolbars, the object-database browser, text-editing views, and so on would use Cocoa user interface.

In theory, you’d end up with less code, better performance, and a modern OS X UI.

Bonus points: custom windows

Sometimes you want to create a mini-application, a custom dialog or window backed by a script. Frontier has a long history (at least on classic Mac OS) of supporting this: you could run dialogs from resources, you could run MacBird cards.

In the year 2004, the thing to do would be to run dialogs and windows from .nib files. You’d lay out your user interface using Interface Builder, then run it in Frontier.

How would you handle wiring up actions and outlets to scripts in Interface Builder? Glad you asked. You probably wouldn’t. One way to handle this is to give each item a unique tag in IB. Then your script might have a handler like on itemDidSendAction (itemRef, actionRef). This would be called when a checkbox was clicked, a button pressed, whatever. Your script would, obviously, have to branch on which item sent the action and what the action was. Not quite as slick as wiring up actions, but it would work.

The other side of the coin is outlets. That’s where tags come in. To get a reference to an item, you might write something like itemRef = cocoaWindow.itemWithTag (tag, windowRef). Then you could do things like set the value of a text field like so: cocoaWindow.setStringValueForItem (itemRef, someString).

Double bonus points

Get PyObjC in the mix of all this, and now you’re talking about something extraordinary.


It’s possible that there will be an exciting burst of creativity once the kernel is made open-source. I think that’s totally cool, it it comes to be. For my part, I’d be happy to answer any questions I can for people who work on the code, since I know a little about it.

It’s entirely possible that the things I’d like to see are not the things most people would like to see, and that’s fine. (But I can dream, right?)

P.S. A glimpse into the kernel: The first thing you’ll discover is that, before Frontier was Frontier, its name was Cancoon.

About NetNewsWire Lite

Peter R. Wood asked on the comments earlier if there would be any commitment to releasing new versions of NetNewsWire Lite.

Yes. We plan to continue NetNewsWire Lite. It will continue to be free. The next release of Lite will ship on or about the same day NetNewsWire ships.

Collegiality clause

I’m thinking of doing something a little radical. Please tell me if I’m all wet or not.

I believe, strongly, in three things:

1. Collegial competition is better than enmity. For instance, I have a policy about not criticizing other feedreaders or their developers. Illustrating distinctions is cool, but in a professional way. Saying that X sucks or Y is stupid or Z is bad is not cool.

2. I like it when apps inter-operate; I like it when apps are compatible. I like this as a user, because it means choice, and I like it as a developer, because it means I can help make users happy, and it means I can promote #1 above.

3. The above principles are related.

One of the things I’m most proud of in NetNewsWire is that I documented the clipboard formats NetNewsWire uses, and that a bunch of other apps now support those formats too. This means you can drag (or copy-and-paste) headlines and feeds into those other applications. (It’s possible, though I haven’t tested it, that other feedreaders also generate the same formats, which is cool if true.)

Even though I know how it works, I still think of it as a form of magic.

So here’s what I’m thinking...

In NetNewsWire 2.0 there will be a few more things like that clipboard format, new things that I’ll document and encourage other developers to support.

This makes it so apps are more compatible, so they can work together, which makes users happy (and, frankly, delights me personally).

What I’m thinking is that I could put a collegiality clause in the documentation of these formats. It would say something like this: “By supporting this format, you agree that drawing distinctions between your application and competing applications should be done in a professional manner, and that expressing strongly negative, subjective value judgments is not professional.”

Obviously, this isn’t something that could be enforced, but it’s something, at least, a good step.

Millard Fillmore and Andrew Jackson

To show what I mean, let’s invent two feedreaders and their developers.

Millard Fillmore has taken a wild approach—his app is a lot like iCal. His idea is to emphasize the time-based element of feeds. It includes full archives, going all the way to back to when you first started using the app. Lots of people like it for its strengths as a knowledge-management tool, though it’s not as good when it comes to just skimming through the headlines as other feedreaders.

Andrew Jackson, on the other hand, took as his inspiration John Norstad’s venerable NewsWatcher application. (Which, if you weren’t a Mac user way back when, was a great Usenet newsreader.) Jackson’s feedreader is great for skimming headlines, but Fillmore’s app has more knowledge-management features.

Both developers, in promoting their applications, could talk about the different approaches in a professional way, recognizing that different people have different needs.

Or they could go negative.

Fillmore writes, “Syndication is the TiVo of the Web. Jackson’s brain-dead application takes no notice of that fact. I can’t believe anybody uses that piece of crap.”

Jackson writes, “The whole point of syndication is to make it easy to see what’s going on right now. Fillmore’s stupid app, with its clunky calendar-based UI, totally gets in the way. I can’t believe anybody uses that piece of crap.”

That’s the kind of stuff I don’t want to see. It’s not only bad for the developers, it’s bad for users, since Fillmore and Jackson are not going to work together on anything, which means users don’t get the benefits of compatibility and inter-operability.

Maybe I’m all wet...

I like the idea of promoting collegiality, but I’m not sure this the way to do it. It’s just something I’m thinking about.

I trust you’ll tell me if I’m nuts.

More about NetNewsWire 2.0

People have been asking me—even on our bug tracker—if there’s an update to NetNewsWire in the works.

Yes! There is.

The next release will be NetNewsWire 2.0. We’re shooting for a public beta in the first half of June, and we hope to ship by WWDC. It could be later, of course, since we won’t ship it before it’s ready.

(Since Ranchero Software is mine and Sheila’s company, and not some big software company, we have the luxury of listening to the craftsman in us that tells us that quality is worth the extra time.)

It will be a free upgrade for 1.x users. If you bought (or if you buy) NetNewsWire 1.x, all 2.x versions will be free. We won’t do this for every major upgrade, but we’re doing it this time.

A number of people who already know about this policy have asked if my head’s on straight. An upgrade fee would be reasonable, they say, and there’s nothing wrong with asking people to pay for all the new features.

Here’s why it will be a free upgrade:

NetNewsWire has sold n copies, but the number of copies we could still sell is n times some large number. The number of people that could benefit from a feedreader is huge compared to the number who are already using one. So we’d much rather concentrate on new sales, and at the same time reward people who’ve already supported NetNewsWire.

This is a very different case than, say, Photoshop or Microsoft Office. Those markets are saturated: they have to charge for upgrades. While NetNewsWire is a successful product, it’s not in the same position as Photoshop.

Another question you might have is...

Why 2.0 instead of 1.1?

Though this release was originally going to be 1.1, a big part of the reason for that was that we didn’t want to do upgrade fees. Then we realized that it could still be 2.0, and we could just not do upgrade fees. Problem solved.

One of my peeves is when software companies use version numbers as marketing. How many times have you seen a product go from 1.0 to 2.0 (or 2.0 to 3.0, etc.) and then scratched your head because there weren’t very many changes? It’s happened to me many times. It’s dishonest.

The changes in NetNewsWire warrant the 2.0 designation. (I listed some of the changes back in April. There are some other changes not on the list, still under wraps for now.)

Also, making it 2.0 instead of 1.1 gives us the freedom to make some of the more radical changes we’ve wanted to do. And that’s a good thing: it’s all about making the software better.

Summing up

The upshot is this: we’re working full-throttle on 2.0, and plan to be in public beta in the first half of June. It will be a free upgrade: all 2.x versions will be free if you’ve bought (or if you buy) NetNewsWire.

WWDC BOF on Syndication and Web Services

At WWDC there will be a Birds of a Feather meeting called “RSS, Web Services and Online Content in Cocoa Apps.”

Fraser Speirs asked me if I would participate, and I said I’d be happy to. So, if you’re going to be at WWDC, and this stuff interests you, I hope to see you there.

RSS Advisory Board, not on

It was mentioned on Scripting News a few days ago that I’m no longer on the RSS Advisory Board. This warrants some explanation.

I originally joined the RSS Advisory Board for two reasons:

1. I thought that moving and re-licensing the spec was an ethical move that I wanted to support.

2. I thought that it would lead to some peace in the standards wars. Not that it would lead to convergence or one format winning, just peace.

I continue to believe that it was a good thing to move the spec to Harvard and use a Creative Commons license. However, I was guilty of wishful thinking on the second point.

Worse for me is that some people thought that I used my software as advocacy. Some thought I was an anti-Atom partisan, and others thought I was an anti-RSS traitor. Both notions are false. My job is to support both formats, as peers, in my software, without favoritism. And if another format gains popularity, I’ll support that one too. I care about my software and NetNewsWire users a million times more than I care about any one format.

The situation of supporting multiple syndication formats is not new with Atom: Atom is the third major format. The other two are RSS 1.0 and RSS 0.9x/2.0. (I’m speaking in broad terms: I’m well aware of the differences between various versions of RSS.) My point is just that newsreaders have been dealing with multiple formats for a long time.

I wish the new RSS Advisory Board all the best, and I wish all the folks working on Atom all the best.


So Sheila’s in Transylvania for a couple weeks doing some family things, and my cat Papa and I are looking at each other wondering who’s going to deal with all the things.

His stare says, hey, you’re the monkey with the brain, you’ve got the cool thumbs, you do stuff, I’m going to curl up and dream about rabbits.

Well, I think, okay.

Tip for working around the security bug

I got a tip I’ll pass along on dealing with the OS X security bug.

If you change the protocol helper for "help" URLs, then the script should not run. I downloaded the More Internet Preference Pane and changed the handler for "help" to the Finder.

It turns out that the bug is more widespread than WebKit—even non-WebKit browsers such as Camino may be vulnerable.

(Thanks to Rob McNair-Huff of Mac Net Journal for the tip.)

Mac OS X security bug and NetNewsWire

Recently a security bug was reported in Safari. Clicking on certain URLs could cause a script to run on your machine.

Sylvain Carle alerted us to the fact that this security bug is not really a Safari bug, it’s a bug in WebKit.

WebKit is Safari’s rendering system, provided by Apple as part of OS X, which other applications use too—including NetNewsWire.

NetNewsWire uses WebKit to display feed descriptions, so NetNewsWire (and other WebKit-using applications) may be vulnerable to this bug.

We certainly expect that Apple will fix the bug with a security update, and that should solve the problem. In the meantime we’re looking at the possibility of fixing it just for NetNewsWire, in case Apple doesn’t come through with a fix.

For reference: here’s the report on the bug, and here’s a CNET article about it, which states that Apple is aware of the issue.

If you have any questions, please feel free to email me at

Frontier kernel open-source

Dave Winer announced that the Frontier kernel—the C code, the internals of the application—will be made open-source. I’m glad: I think it’s a good thing for Frontier and Radio and their users.

During the latter part of my stint at UserLand I worked on the Frontier kernel. A big part of my efforts were on Carbonizing it. Timothy Paustian started the job, and handled all the really crazy low-level stuff like threading, then I did user interface stuff and fixed bugs. In some cases I was able to adopt the Aqua appearance, but going all the way with that would probably have tripled the development time. At least.

Anyway, what I love about the kernel is the way it is written in C but is nevertheless object-oriented. (Remember that it was started in the late ’80s, so C was the natural choice.)

The way it’s done is via the use of structs instead of “real” objects. These structs contain function pointers, so one object can inherit from another and have not just different data but different methods.

I found this to be surprisingly elegant, so much so that now, years later, I sometimes get the urge to write in C just so I can use this style of object-oriented programming. (But then the urge passes, and I stick to Objective-C.)

Challenge/response email is evil

I detest challenge/response email.

Last week a journalist sent me some interview questions. I answered them later that day.

Then today I got an email me asking me if I would have time to answer the questions, since the article is nearly due.

Clearly my reply didn’t get to the journalist. I was wondering why, and then I noticed his email address and went to the website. It’s one of those spam-blocking systems that uses challenge and response.

I don’t remember seeing a challenge. But I might have seen it and thought it was spam—or my spam-filter might have thought it was spam.

The upshot is that I get way too much email to deal with challenges to a reply to an email conversation that someone else initiated. I can understand a challenge if I’m emailing someone out-of-the-blue, but not if I’m replying to an email.

So I replied again, pasted in my answers, and crossed my fingers that he’ll get my email. I’m watching my trash for a challenge from his email system. This is stupid.

So if you see an article about Atom and RSS and it says something like “NetNewsWire author Brent Simmons could not be reached for comment”—then you know why.

Automatic blogrolls via Perl

Mihai Parparita uses Perl to automatically generate a blogroll from his NetNewsWire subscriptions. I love stuff like this—even though I’m a Cocoa developer these days, I still dig scripting.

Senior moment

I’m too young to have senior moments like this!

- (void) setDirty: (BOOL) fl {
   flDirty = YES;
   } /*setDirty:*/