One of the larger obstacles to adoption has been the lack of a consistent, user friendly mechanism for identifying and subscribing to feeds on the web. A widely adopted auto-discovery markup convention and browser integration have improved the experience dramatically. Publishers now have a mechanism by which they can provide the user with notification that feeds are available. However, in practice, current implementations can give confusing results. This is due largely to the LINK tag convention suffering from the classic invisible metadata problem: data that is out of sight easily falls into disrepair. Broken links, duplicate feeds, and invalid or poorly written titles are common in LINK tags and lead to ambiguous results like this:

There are two distinct feeds associated with this web page, and no good way to differentiate them using the metadata provided in the LINK tags. This is inconvenient for the advanced user and downright confusing for the novice.

Flock attempts to improve this situation by fetching and parsing feeds mentioned in LINK tags in the background as you browse. This lets us validate the feeds, get authoritative rather than secondhand metadata, and gives us the opportunity to use more advanced deduping techniques to provide the user with a more relevant selection:

The end result is a more consistent feed subscription experience on the wild, wild web.

In an ideal world I'd have every last byte of my digital existence versioned and mirrored across geographically distributed data centers. Failing that, I think a ReadyNAS from Infrant Technologies might do nicely. I need a mass storage device with redundancy and plenty of room to grow, but quiet and small enough to stick under the couch. Something I can throw multiple backup disk images at and still have scratch space left over for when the powerbook is down to its last gig. ReadyNAS seems to fit the bill. Anyone out there already using one?

I've always been interested in the work of Jacques de Vaucanson, whose creations were some of the most intricate. They haven't survived the ages, but Vaucanson's duck and flute player are thought to represent the height of the automata craze.

Today, what was once cutting edge tech has become anachronistic curiosity. Which leads me back to a favorite Neuromancer passage:

The most unusual thing Jimmy had managed to score on his swing through the archipelago was a head, an intricately worked bust, cloisonné over platinum, studded with seedpearls and lapis. Smith, sighing, had put down his pocket microscope and advised Jimmy to melt the thing down. It was contemporary, not an antique, and had no value to the collector. Jimmy laughed. The thing was a computer terminal, he said. It could talk. And not in a synth-voice, but with a beautiful arrangement of gears and miniature organ pipes. It was a baroque thing for anyone to have constructed, a perverse thing, because synth-voice chips cost next to nothing. It was a curiosity. Smith jacked the head into his computer and listened as the melodious, inhuman voice piped the figures of last year's tax return.

It seems that James has an up and coming project known as Knowledge Web that aims to enable his tangential style of discovery in an online learning context. As he explains in a related interview, the web-based tool would allow the user to visualize and explore a network of interdisciplinary connections that Burke and other researchers have compiled over time. Think of it as Friendster with renaissance thinkers, monarchs, and modern scientific heavyweights for profiles.

What a great little tool. So clean, lean and fast. Bloody marvellous!

This is the best integration of RSS and a browser i've found!

I don't need RSS support in Thunderbird or the Fox's Live Bookmarks or an external Feed reader anymore. Sage rocks.

In a recent interview, Ben Goodger had a few comments on the road ahead for Firefox as an application framework:

Some of our goals in the next 12-18 months include improvements to the core rendering technology to make web developers' lives easier and also "productizing" the application development platform if you will, so that people will be able to download a "XULrunner" (with Firefox, probably) and then run other compact applications on it.

If the push to neatly package and spread Firefox to end users is the first phase of adoption, the second will be the formalization and popularization of its development environment. Applications drive platform adoption. Right now, the excellent web browsing experience you get out of the box is driving adoption, this is the first application. Soon we'll see the development of third party XUL apps that, in and of themselves, can provide the incentive needed to download and install Firefox.

I'm here to confront you, because we need help from the media and they're hurting us ... you're doing theater, when you should be doing debate ... you have a responsibility to the public discourse, and you fail miserably.

An attack to which a befuddled Tucker Carlson eventually responds: "you're more fun on your show". Apparently, while all else is fair game, Crossfire itself is beyond reproach.

Stewart takes some flak for pulling punches in his Kerry interview, and responds by saying that his role is not that of a rigorous political interviewer. Is their a certain level of journalistic responsibility that should be expected of a program like The Daily Show? Yes. Should Crossfire be held to a higher standard? Absolutely. As Stewart put it, "You're on CNN. The show that leads into me is puppets making crank phone calls."

Are we seeing the rise of a cross platform RSS aggregator that's essentially available for free from an open source group?

Audio Clip

Just as there was a time when people were willing to pay for web browsers, aggregators are now getting their dollars from the early adopters. In time, the core feature set will be commoditized by FOSS projects and commercial offerings will be relegated to advanced users and special applications of the syndication standards. Fanning the flames of the RSS ubiquity push was Apple's announcement of Safari RSS at its WWDC in June. With user expectations raised, Firefox seems naked without a comparable offering. Scott Rafer, CEO of Feedster, remarked:

The Firefox guys have been trying to not upset the variety of Firefox plugins that are decent RSS aggregators, and they're going to have to give up and pick one at some point.. and at some point not very long in the future I would suspect.

Audio Clip

Forumzilla gets mentioned as a candidate for integration. Haven't explored Forumzilla yet, but I understand that it's a Thunderbird extension allowing feeds to be manipulated though the mail reading interface, and that it's the basis for the newly added feed aggregation in Thunderbird itself.

Integrating with the email client does offer efficiency in the form of workflow reuse, but I see the browser as being the ideal spot to land feed reading functionality. The overlap between activities is just too strong to ignore. Sage is an attempt to leverage this overlap, and provide the simplicity required for mass adoption while offering enough features to woo power users. A big and increasingly important step for us will be to provide persistent storage of feed items, opening the door to another level of functionality.

..something that's attracted me back to using Firefox in the last few weeks has been the Sage RSS Reader extension. With a little tweaking to make it look more like an OSX'y, I now have what feels like my ideal Browser/RSS Reader combination.

Jon goes on to provide step-by-step instructions for Sage users looking to make their own visual mods. This is one of the benefits of working with the Mozilla platform.. End User Development. When the barriers to patching an application are unzip and notepad, everyone's a developer. We have a whole group of users poking, prodding, tweaking, and enhancing Sage for their own benefit. Not every mod has broad enough appeal to be incorporated back into the releases, but many do, and all offer insight into use habits.

I was then faced with the challenge of moving my bootable UFS file system from the old disk to an 80GB partition on the new one. I found that Carbon Copy Cloner is a popular tool for Mac disk migration, as it's wise to the resource fork meta data on HFS volumes (the default OS X file system format). Unfortunately it doesn't seem to play nice with UFS, so I kept searching for a solution. Eventually I noticed that OS X's Disk Utility provides disk migration support through it's Restore feature, so I gave it a shot and after around 2 hours of transfer time I had a working copy of my volume on the new disk. I found that creating a bootable image of another disk requires that you select Disk Utility's 'Erase Destination' option in the Restore dialog, this forces a block level transfer as opposed to a file level copy. Without selecting this option I was left with a complete copy of the original, but was unable to select it as the startup disk in System Preferences.

So ends the upgrade saga. Now, not only do I have twice the internal storage in a device the size of half a pack of cigarettes, I've got a larger than expected speedup from the new disk's 5400rpm rotational speed and 8MB cache. Here's to the hard disk industry giving Moore's Law a run for its money.

Note: for those interested in OS X internals, Amit Singh has a section on the Mac boot sequence in his excellent article What is Mac OS X? at kernelthread.com.

[Live Bookmarks] were never intended to be an answer to the power RSS readers or a comprehensive solution to hardcore RSS/news junkies. ... Firefox's RSS capabilities are designed to expose as much of RSS to regular people as makes sense for light news reading/dynamic content.

...and to this end, it's a good start. I can't help but feel that expectations have been set unrealistically high by more involved implementations in Opera and upcoming Safari RSS. Does Firefox need an integrated heavyweight aggregator if it has an excellent extension mechanism?

I want something that does the ranking only from the piece of the pie that I consider important. I want a link or a button on my aggregator which, on clicking, will give me the day's most talked about link or topic.

On a large enough feed list, this might produce interesting results.

Discovery is an important component of the aggregator usability equation and an significant opportunity for Sage as its browser integration gives us the ability to do this well. The goal here is to allow users to find and subscribe to new feeds in the most effortless manner possible. I'm going to suggest that there are two complimentary approaches to feed discovery, a lightweight and a heavyweight technique.

At this point in the game, doing feed discovery is something of a black art. There is an accepted method for explicitly associating feeds with HTML documents, but it has yet to spread to the far reaches of the blogosphere and there are a good number of sites that don't make use of it. This is where discovery gets tricky. Without an explicit feed declaration, the only option is to scan through any links present in the HTML document trying to determine which of those might be pointing to a valid feed. There is no feed URL naming convention, so these links can look like anything. Sometimes they're obvious, sometimes they're indistinguishable from other links in the document.

The heavyweight approach is to cover all the bases by checking for explicit feed declarations as well as scan the document identifying feed links in the case that there are no explicit feeds. This is what happens in Sage when you click the 'Discover Feeds' icon. All potential links are probed, meta data is collected for those that turn out to be valid feeds, and the results are ranked by relevance and displayed to the user. The benefit to this approach is the quality of the output, if there's a feed to be found, we'll probably get it. The downside is that it's expensive. It takes network bandwidth and CPU cycles to probe the links in a document and this means you won't get instant results. It also means it would be difficult to perform automatically in the background as the user browses.

The lightweight approach doesn't scan the document body for links to probe, but looks only in the <head> section for explicit feed declarations. If these are found, great, you've got some URL's that probably lead to valid feeds and enough meta data for the user to choose between them. This method is inexpensive and can quickly be done at the users request or in the background as they browse from page to page a la Firefox 1.0 Livemarks and Safari RSS. The downside is that it will come up empty handed on any site that doesn't explicitly list its feeds.

For now, I think the answer may be to make use of both methods, a lightweight discovery process running in the background during regular browsing, and a heavyweight catch-all mechanism available at the user's request. Lucky us, it appears that we're being given that lightweight process with the new Livemarks functionality in Firefox 1.0. In the interim, we should be able to piggyback on this feature, giving users access to automatic feed discovery.