What's Next? A Conversation about Web Communication with XML Pioneer, Tim Bray

Print-friendly Version

Consumers find themselves with a wide array of communications options: snail mail, phone, email, instant messenger, video phone, web publishing, fax, and, increasingly, Really Simple Syndication (RSS) feeds, driven by everything from newspapers to weblogs. Everywhere, individuals and businesses are trying to make the most effective use of communications technology, while IT companies decide which technologies to bet on. In this context, XML pioneer Tim Bray joined Sun Microsystems in March 2004, where, as Director of Web Technologies in the Software CTO Office, he plans to incorporate blogging software and content syndication based on the RSS format into Sun's software line, and help set the company's direction with respect to web services and search technology.

Bray was one of the three editors of the XML 1.0 specification and the author of the first "parser" software designed to read XML documents. Prior to coming to Sun, he served as chief technology officer for the visualization software company he founded in 1999, Antarctica Systems, Inc.

We met with him recently to explore the future of RSS and web-based communication.

James Gosling recently put together from scratch an RSS feed reader called JNN, for "Juicy News Network." Available under the Berkeley Software Distribution (BSD) License, the Juicy News Network feed reader is an open source project at Sun's java.net site via JNLP (Java Network Launching Protocol). Gosling commented, "The most interesting thing is what it does to be fast at startup: all news feed reading is done by a swarm of low priority threads, one for each feed. So all feeds get fetched in parallel. This is very easy to do in Java: the threading API and networking support made it all straightforward. All the sources are there, as well as a JAR file that works on any platform, and a Mac OS X installation." Any reaction?

The interesting thing about JNN is that James, to use his words, pulled it together as "a weekend hack." This illustrates how simple and straightforward syndication technology is. In this domain, the technology is the easy part.

"RSS works well in areas where information arrives at irregular intervals, like news and publications, in which you don't want to waste time looking for information." - Tim Bray, Director of Web Technologies in the Software CTO Office

RSS is typically used as a web publishing tool. You have said that you would like an RSS feed to your bank account, credit card, and stock portfolio. You have compared where we are in 2004 with RSS, with 1993 when the web was taking off. Where are we headed with RSS?

There are many ways to communicate. There's email, the telephone, fax, instant messaging, and increasingly, video instant messaging. RSS is one more way to communicate, and the range of communications for which RSS is applicable is quite large. RSS works well in areas where information arrives at irregular intervals, such as news and publications, in which you don't want to waste time looking for information -- you want to be told when it shows up. So, right now, RSS has a huge sweet spot for bloggers and for news sites such as the New York Times and the BBC World Service.

But a lot of useful information, such as stock market portfolios and credit card transactions, arrives at unpredictable intervals. RSS users don't need to repeatedly visit their favorite web sites to check for updates, because when the site changes, they are notified quickly with a summary of what's new. To know when one of your investments changes substantially in price, or to be able to track debits in your bank account, is inviting.

Possibilities abound. RSS might be useful for tracking change requests during a software build or for bug tracking. So, there's a lot of information that people would like to be automatically notified about.

It's too early to know all of the RSS sweet spots, or when RSS will work better than email, instant messaging, or a phone call. We do know that RSS is going to be a major part of the communications spectrum, along with Java software.

RSS is strongly identified with blogs, but as you suggest, its uses extend far beyond blogs.

Right, blogs, almost by definition, use RSS, but there are many applications of RSS outside the blogging space. Basically, anybody who's blogging now is producing RSS. The fact that so many RSS feeds exist suggests that, of course, you would want to aggregate them. And there are people who are starting to do that. Technorati (http://www.technorati.com/) aggregates huge numbers of RSS feeds, and allows you to subscribe to the aggregates, or search them in real time. It's very different from a Google search, and a potential game changer. No one can predict where all of this is going at this point. But it's a space we're very interested in, and we want to do the right thing in.

For developers who have not adopted RSS, how can it impact the way they work, communicate, and organize information?

Any business or person providing information to others would probably benefit from RSS. Already, I have spoken with my new colleagues at Sun about providing RSS streams whenever posting new content to a portal. We're not yet talking about a product, but it could happen.

"Given the decreasing cost and increasing reliability of memory, there's a growing class of enterprise applications that could run everything out of memory." - Tim Bray, Director of Web Technologies in the Software CTO Office

What are the biggest misconceptions that developers and IT people have about RSS/XML syndication?

People addicted to RSS tell their friends to check it out. Often, their friends say, "I don't have time to read weblogs." Remember people in 1993 saying they did not have time to surf the Internet? This is maddening, because RSS is actually a huge time-saver. There are two misconceptions. One is that RSS is just about reading blogs, and the other is that blogs are not worth reading. Some of the most influential voices in technology and business are on weblogs.

Where do you stand on the effort to merge the RSS standards groups with the Atom group, which provides an alternative or complement to RSS?

RSS and syndication in general would benefit from having a formal standard, blessed by a standards body with a carefully reviewed specification that developers could download and use. So I'm 100% in favor of getting such a standard. I don't really care whether it's called RSS, or Atom, or RSS/Atom or whatever. There are several similar versions floating around. It's not rocket science. A solid, single, agreed-upon set of rules would be ideal.

You mentioned the wide and proliferating spectrum of communication, ranging from snail mail to video phones and so on, that individuals and businesses are trying to make the most effective use of. Do you have any insights as to where this is headed culturally or technologically?

The ground is changing beneath us. The actual costs for me to send an email, or write a blog entry, or send an instant message, or to call you on the phone are all pretty close to zero. So, cost isn't really a factor in choice of medium. Rather, it's about effectiveness. We've gone from speech, to writing, to telephones, to electronic mail. Our methods of communication are now broad. Eventually, we will determine the best use of all these options.

Java Software and .NET

You have said that the claims of pundits that .NET is a threat to Java technology's future are silly. And that .NET fails to hit the 80/20 point where you do 20% of the work and see 80% of the benefits.

Java 1.0, when it first came out, was very lean and mean. And that was excellent, because people could learn it and become proficient in it quickly. Since then, the Java language has grown into its current, sophisticated, expansive shape. It's going to be tougher for .NET to replicate that kind of successful growth.

Many of the design decisions about .NET were made before it came out. But with Java 1.0, the community collectively was able to build all the extra layers that make up what we have now.

"I think we're going to beat spam." - Tim Bray, Director of Web Technologies in the Software CTO Office

.NET was created by a company with a historic focus on desktop applications. My view, though somewhat controversial, is that delivering applications through web browsers versus through custom applications is much preferable. And the CIOs of the world generally agree with me about this, because maintaining desktop applications increases total cost of ownership. It's much easier to deploy, maintain, and update server-based applications and interact through a web browser. And when the web browser appeared in the mid-90's, its popularity was obvious. People migrated to the browser for just about everything in very short order. Browser-based applications are the sweet spot for the entire industry.

Cellphones and PDAs with Java applications obviously have a role to play. But for the mainstream enterprise, PC/desktop, browser-based apps are the way to go. And Microsoft is all about being a desktop company. They have a place on 95% of the world's business desktops, and they have an immense depth of experience about desktop applications and how to build and deliver them. And that shows in .NET. .NET has a huge amount of user interface machinery, which is a distraction from where the real sweet spot in business is, which is on browser-based applications.

Memory -- the New Disk

You made the intriguing comment that memory is the new disk, and disks are the new tape. You argue that enterprise applications aren't architected taking this into account, and suggest that you have ideas how they could be. Would you share some of your ideas along these lines?

Very high-performance global applications, such as Google, achieve much of their performance by running in memory, and not using the traditional disk database. Given the decreasing cost and increasing reliability of memory, there's a growing class of enterprise applications that could run everything out of memory. This is going to require different thinking, both about how we build applications and about the required infrastructure. And since I think that enterprise applications written in the Java language are going to continue to be written in the Java language, we should think carefully about the kind of infrastructure necessary to support 100% memory-resident applications. I hope to work with people at Sun on this, and perhaps build some prototypes on my own.

XML Clunkiness

You are one of the three editors of the XML 1.0 specification and the author of the first "parser" software designed to read XML documents. As you know, some developers have complained that XML is too hard. They've said it's too complex, too hard for programs to parse, too verbose, and unreadable for humans to write. They say the benefits of having everyone use XML are more than outweighed by the cost of time, training, and mistakes.

I think that, despite XML's success, the APIs available to programmers for reading, writing and manipulating it have been rather clunky. It's not surprising, given XML was only finally blessed in 1998. The APIs are getting better. Yet still, the bookkeeping and code required by XML are sources of irritation. There's lots of room for improvement.

Winning the War with Spam

What about the war against spam?

I think we're going to beat spam. (You can search for spam on my blog where I've written extensively about this.) If everyone paid a penny per email sent, the cost would be very small, but the cost to spammers would be great, and spam would stop. That's my proposal.

See Also

Tim Bray's Web Site
Sun Developer Network RSS Feeds
Sun Developer Network Content Syndication FAQs
Technorati
Blogging and Sun