I got a feeling

A feeling deep inside.

Oh yeah.

1 2 3

A Busy Developer’s Guide to RSS 2.0

Disclaimer: This is not spec text.

Okay, so you’re busy and you’d like to get a quick implementation of RSS up asap and have it work with the largest number of feed readers and aggregators. Coool. Here are some tips for that will make your work go more smoothly, based on the experience of real developers.

1. Find a feed that’s popular and do what it does. This is the best advice you can get, for any format any time. If you do exactly what the New York Times does, or what Yahoo does, or what my feed does (it was the first) then you can’t go too far wrong, because all the feed readers will have had to deal with whatever these feeds do, because they are so popular, and old.

2. If you’re doing a podcast feed, at most one enclosure per item. There’s been some controversy about whether or not you can have more than one, and the spec doesn’t specifically disallow it, but if you want maximum interop, you shouldn’t have more than one enclosure per item.

3. No relative URLs. In your descriptions, and in links, all addresses should be absolute. Most readers and aggregators won’t do anything special with relative URLs, so your links will be broken in those tools if you use relative links.

4. Don’t include markup in any elements other than descriptions, at the channel level and at the item level. Where you include markup, you should encode ampersands and less-thans in the way proscribed recommended for HTML by the W3C.

5. Avoid using elements in namespaces when there are already core elements that do the same thing.

6. Use namespaces that are already in use by others before inventing new ones.

Notes

1. Thanks to Tim Bray for providing a great checklist to work from. 🙂

2. If this actually gets used by a lot of people, perhaps we should have a way for a feed to notify a reader that it is following these guidelines.

3. This is an informal document, and always will be, and it’s still very much a draft and a request for ideas. It is not spec text. If you think something belongs in this profile, post a comment, let’s consider it.

4. If have strongly differing ideas, please by all means, post your own BDG.

5. Some people will say I’m stupid, or corrupt, or incorrigible, even toxic, or any number of negative personal things. What they’re really saying is they don’t like me. That’s okay, no one is liked by everyone. It doesn’t hurt my feelings, and you shouldn’t worry about it, because I don’t.

6. Namaste y’all!

Getting my data out of Flickr?

I was at lunch today with Mike Arrington and a question came up — how do I get my data out of Flickr? I found out the other day that my RSS feed only has the ten most recent pictures in it. So how do I get the rest of the pictures out?

Don’t dis your competitor

There are some very practical time-tested reasons for not dissing your competitors on a personal level.

Like it or not you share a market with this person. How are you ever going to woo away his customers by saying nasty stuff about him to people who like his product? If you waste time talking about the person, people will quickly assume your product isn’t as good as his.

Instead, try saying something like this. Paul is a hell of a nice guy, and his product is excellent, but ours works better for people like you. Hell, if it were about who’s nicer, you should buy his product because he’s much nicer than I am, and smart as a whip! But as luck would have it, our product is better for you. It has more vitamins, gets better mileage, lasts longer, smells better, gets the job done faster, for you, the most important person in the world.

Now if you make it all about how the guy who makes the other product hasn’t bathed in a month, and flunked a math test in 7th grade, well that leaves people wondering why you aren’t talking about the product.

Maybe it’ll turn out that your product is better for one thing, and theirs for another, and everyone can be happy. But dissing your competitor on a personal level makes you look like a loser.

How to save a Gmail message?

This should be a real simple thing to do but I can’t figure out how to do it. I have about a dozen messages in my Gmail inbox that I want to save to my local hard disk. How do I do it? I’ve scoured the online help and have come up with nothing. I admit I should have checked this out before making it my main mail system. I hope the answer isn’t Save Page As in the Firefox File menu.

This is a test post

I am at the headquarters of SixApart in San Francisco, and we’re going to see if we can get this to work with Movable Type.

Niall and I are heading over to SixApart

Matt Mullenweg wouldn’t come out to play, so Niall and I are going over to SixApart to get WordPress.root working with Movable Type. Hehe.

This a demo of the software I is talking about.

The mystique of desktop web servers

Q: What is a desktop web server?

I guess it should be no mystery, it’s a web server that runs on your desktop.

Q: What makes a desktop web server different from one that runs on a server?

Not much. You could run Apache on your desktop. In fact, if you’re using a Mac, you are. When the time came for Apple engineers to decide to turn off the server, they thought, what the heck, let’s leave it on and see what happens. Unless I’m missing something, so far not much has, but it could.

Now let’s zoom back to 1998. I want to explain a decision I made in January of that year. We had almost completed the port of Frontier from the Macintosh to Windows. I was using the Windows version. We still we had to recreate a networking layer that would do for us on Windows what Apple’s networking, AppleTalk, was doing on the Mac. We could have used Microsoft’s proprietary networking, it was called COM, but since I already saw myself as an Internet developer, instead I wanted to use the Internet to connect my computers.

This had several important advantages.

1. I could connect my Macs and Windows machines using the same protocol.

2. Since there is no platform vendor for the Internet, they couldn’t break us, like commercial platform vendors always do. Read the thread on Apple’s latest RSS crap to get an idea how that works. Even if they’re well-intentioned, they still don’t care about the little guys, you know, like you and me. ;->

3. I could connect to Unix machines for free.

4. I could connect to anything that comes along later.

5. I could connect computers that were very far apart, since the Internet is a world-wide network.

Those are all pretty compelling reasons, so I announced my intentions and went ahead and it happened incredibly quickly, we created a new networking layer, and not only was it quite useful for our users, it went on to become one of the biggest defacto standards of the Internet, almost as big as RSS, but not quite so visible (since it’s really plumbing and largely of interest to developers although users like what they do with it).

Anyway, there was another reason this approach was cool, because it built on XML and HTTP, we got a web server for free. And thus was born UserLand’s web server. It’s built into Frontier, Radio and the OPML Editor. Every time you install one of these programs, you get a web server. People use it all the time, but they’re probably not even thinking about it, and most of them aren’t even aware of it.

This really came home to me in a conversation with Mike Arrington yesterday. I was trying to explain the Aggregator API that was released yesterday. He didn’t understand that there was a web server in there, and that you could put an API on it even if it’s running on the desktop. Why not, a lot of APIs are running on the desktop (that’s largely what Windows is).

I told Mike that it didn’t matter where I ran the software. Most people ran it on the desktop, but you could put a copy of the OPML Editor on a server and access the aggregator from afar. I guess it’s a very new idea (even though it’s already 8 years old) that you can use the protocols of the Internet to connect two apps that run on the desktop, but you can, we do it all the time. It’s very general, and quite powerful, and flexible.

The Internet is not just a world-wide network, it’s also a local area network, and it’s can be an inter-application communication protocol, for two programs running on the same machine. The same simple protocol can be used in all these contexts.

To prove the point, I put a copy of the NewsRiver aggregator on a server of mine in Massachusetts that I’ve never actually seen. It’s definitely not running on my desktop. Here’s a link to the aggregator running on that computer. Go ahead and try it out.

http://test27.newsriver.org:5337/newsRiver/

Note, this link may not work tomorrow or the day after. ;->

PS: Another example of desktop web servers, Google’s desktop search. You access it through a web browser, but the software is running on your computer. Ever stop and think how that happened? It’s so simple people don’t even notice.

PPS: I wrote a piece that attempted to define desktop web servers at the beginning of 2001. I thought that would be the year of DTWS’s. It wasn’t. We still haven’t had an explosion of creativity in this area, but I think there’s still reason to believe we’ll see it, eventually.

PPPS: I wrote a piece in 1998 that explained in fairly non-technical terms how APIs work. Anyone trying to understand the basic concepts of what we now call Web 2.0 should master these concepts or else you’re just talking marketing BS. Maybe you already understand APIs, if so, good for you! But if you’re still scratching your head, the concepts really aren’t all that hard.

The wonderful world of Apple RSS

Here’s an example feed. You can’t read it in Firefox, and I haven’t been able to get NewsRiver to read it. They must look at the User-Agent header and only return if it’s their browser. Apparently it works with NetNewsWire. What are they doing at Apple?

Well, it’s not a User-Agent thing, it’s looking for a plugin, and it’s only present in Safari. The feed displays in Safari, but I haven’t been able to get a look at the XML source. To say this is somehow RSS is pretty wacky. Did Jobs really say it’s “industry standard,” as Engaget quotes him? I’d love to see some evidence of that.

Wait Phil Ringnalda spotted the url to the “real” feed.

http://web.mac.com/mrakes/iPhoto/photocast_test/index.rss

I couldn’t read that in my browser, so here’s a copy.

http://static2.podcatch.com/blogs/gems/snedit/rss.xml

It’s pretty bad. There are lots of errors, the date formats are wrong, there are elements that are not in RSS that aren’t in a namespace.

Engadget quoted Jobs as saying they were using “industry standard” RSS. Even if we used terminology like that (we don’t, there’s no standards body for RSS) one company can’t on its own say it’s standard, esp when it has so many mistakes in it. It’s a fairly damaging lie. Yeah, companies lie, I know — but then sometimes bloggers have to say they’re lying.

Assuming their intentions are good and they’re not trying to kill RSS, why don’t they put some of us under NDA and let us help them get the bugs out before they ship.

See Brent Simmons’s blog for more comments.

More than a common export format

As discussed in the comments of the previous post on this subject, a commonly supported export format is an important first step, but it is not enough. Here’s what else is needed.

1. The export must be automatic. It must be done by the software, and kept up to date. The user must not be required to do anything to always have a good backup.

2. The backup must be stored on a static server, not on the vendor’s network. There should be a default backup service provider, but the user must be allowed to specify a different one. Apple, for example, could do this as part of their dot-mac service. I believe other companies would line up to provide such a service.

3. The user must also be able to remap their sub-domain. The user should have full control over the domain for the site, and it should not require any help from the vendor to map it to different server. An alternate, though not as desirable approach would be to allow a permanent redirect, again triggered only by a user action. The problem with this approach is that it requires that the vendor’s server be working in order for it to work.

With these three things, in addition to a common export format, even in an extended outage, the user would be in full control of his or her content. Users should insist on this level of support from vendors, or take their business to vendors who provide it.

Having been a vendor myself, I believe this kind of system will allow vendors to relax too, in addition to the users. When you have an outage, the users will have the power to move, and no doubt some will, but it takes the pressure off the vendor, and gives them time to fix the problem.