real, I mean
Mozilla-based. (That's not fair; it works flawlessly in the latest version of Opera too.) You should get a page that looks very much like the rest of my site, with a friendly little blurb at the top explaining a little about syndication and what this
feedthing is that you just clicked on.
This is not an original idea; Blogger does something similar for all of their feeds. In fact, the blurb at the top is the info element, which was originally proposed by Jason Shellen, a Blogger employee, and later refined in Atom 0.3 to make the content model match other Atom elements. Their blurb points users to the Blogger Knowledge base, which seems reasonable. The wording of mine is open for discussion.
What is new here, I believe, is the use of inline XHTML (properly namespaced, of course; this is still a valid Atom feed) to add a few other things to the page for browser users. The page header is a series of <div>s (the images and positioning are entirely defined in the associated CSS file, just like the rest of my site), and the breadcrumb trail is also a piece of hard-coded XHTML wedged in the middle of the feed in the appropriate place.
I have tested this with a number of Atom-enabled aggregators, and none seem to have any problem with it. Let me know if your Atom-enabled client misbehaves.
Note that the display doesn't look right in IE/Win. I am shocked, shocked. Also, the links don't work in IE (the breadcrumb trail should be clickable except for the last bolded link, and the letters in the page header should be clickable).
Instead of styling XML with CSS, another potential solution would be to associate it with an XSLT transform and let the client convert it to HTML. This would probably solve the cross-browser-CSS problem, since I could just transform it into exactly the same markup I use elsewhere throughout my site. It would also create all new, even more exciting problems in trying to create cross-browser XSLT.
Update:
The entry titles aren't links in any browser, but they're not meant to be. Some have suggested they should be, but I disagree. I don't want to make this page *too* useful in a browser. I do not, for instance, want people visiting this page all the time in their browser. I just want to make it friendlier to first-timers (or accidental click-throughs) than dumping raw XML. The one and only goal of the page is to get visitors to subscribe to the feed in a feed reader.
Others have noticed that I've switched from application/atom+xml to application/xml to get this demo to work. Yeah, that sucks. application/xml is correct, in the sense that it's not wrong. It's not optimal, but at least it's not text/xml. Oh God, let's not have that discussion again.
I'm surprised no one has pointed out the irony of my using inline XHTML at all, given my strong and well-publicized opinion of XHTML for general use. In fact my HTML is virtually XHTML anyway, except for unclosed <img> tags. I may employ some quick regular expressions and inline XHTML for the full content in my feeds, since Atom supports that and all Atom-enabled aggregators I've seen support that. As I've mentioned before, this is the only real use I've seen for XHTML. And then I could display the full content on my styled-for-browsers Atom feed. (Sam does this.) Not sure if that would be an improvement worth making.
Text editing: GNU/Emacs. All non-cross-platform editors are out; I do serious text editing (read: writing 500 page books in Docbook for money) on too many platforms on a regular basis to learn new keyboard shortcuts and macros, or to try to remember where I am today. All editors that don't work identically in console mode (over an ssh connection) are out for the same reason. All non-macro-customizeable editors are out. All non-syntax-highlighting editors are out (I work primarily in XML, XSL, CSS, HTML, Python, and recently Java).
That doesn't leave a lot. I know you can script vi with Python, and I know you can use real arrow keys now, and I've tried vi and vim and gvim and Lemmy and all the rest; they just don't fit my brain. I've tried XEmacs, but its dired functionality works much differently than GNU/Emacs, and I use dired a lot, and I like how GNU/Emacs works better. I did steal a bunch of the packaged editing modes from an XEmacs installation and throw them in my GNU/Emacs site-lisp, though, so thanks for that.
Reasons I would leave GNU/Emacs: XEmacs really is nicer in many ways, much more professionally packaged and maintained. If I'm feeling brave, I might give it another shot and see if I can get its dired to make sense to me. Oh, and an official Mac OS X port would be nice; I'm using this unofficial build of GNU/Emacs for Panther, which works well today, but it's no longer being maintained. *sigh* There's always nightly builds (thanks Michael).
Web browsing: Mozilla Firefox. Again, all non-cross-platform browsers are out; I set up my preferences identically on all platforms and rely on those preferences wherever I am.
Reasons I would leave Firefox: some important UI feature, or lack of support for some emerging web standard. I've seen all the emerging web standards, and I don't see any must-haves.
Mail: Mozilla Thunderbird over IMAP. Identical cross-platform functionality is less of an issue here, since I don't spend that much time in my mail client (relatively speaking). But IMAP is essential (too many computers, and all webmail systems suck, and the ones that don't suck have no data export), and Thunderbird's IMAP support is top-notch. Mail.app is close, and it has better indexing and searching. Every few months I take all the messages I no longer care about having easy access to from anywhere, and download them to my Mac via Mail.app via POP, stick them in folders based on year (I have mail going back to 1993), and those mbox files get thrown into the daily backup rotation and archived in multiple places. A few times a year, I find a reason to search all my mail for something, and I do it in Mail.app. Of course if my Mac is not convenient, I can ssh into it and grep through the mbox files manually.
Reasons I would leave Thunderbird: stopped being actively developed, while having showstopping bugs.
Reasons I would leave Mail.app: when GMail supports bulk import and easier SSL support (yes I know you can get it by manually changing the URL... every time you log in), I would consider using it as a searchable repository. I would still use some local solution like Mail.app for permanent archiving. Even Google won't last forever.
XML parsing: libxml2. It's faster than anything, has bindings for everything, and is insanely conformant to all specifications it claims to support. Also, it integrates with libiconv to handle every character encoding ever. Why doesn't everyone use iconv? Character encoding is a solved problem.
Reasons I would leave libxml2: none.
Remote connections: ssh. An obvious one, but I'm surprised how few people know how much it can do. I set up SSH all the time to forward random ports from one machine to another. I tunnel rsync over ssh. I tunnel cvs over ssh. I send outgoing mail by forwarding port 25 to my mail server (this is in fact the only way to send mail through my mail server; I've set it up to only accept outgoing mail from local users).
Reasons I would leave ssh: none.
Backup and mirroring: rsync. rsync -essh -rtpvz rocks. Really, there's nothing more to say. Learn it. Use it. Love it. Here's a good rsync anecdote: in my last job, I worked on a project that was doing daily (and sometimes more-than-once-per-day) builds of a 100 MB installer. Near the end of the release cycle, we were putting each daily build on a private web server for the client to download and test. Uploading the entire build took over a hour on my capped DSL line. It turns out that the fastest way to do this is to ssh into the server, duplicate yesterday's build to a file with today's date, then rsync today's build up to the server. rsync magically figures out which parts of the installer have changed (usually not more than a few KB) and synchronizes the build in under a minute. I have no idea how it does that. I read once that it was somebody's PhD project. Thank God for smart people.
If you're mirroring stuff from one Mac to another, and you care about resource forks, install RsyncX on both machines and breathe normally.
Reasons I would leave rsync: none.
Web server: Apache. IIS is out because it only runs on Windows. I'm not interested in specialty web servers (I've tried, for internal projects, and always eventually needed enough functionality that we switch to Apache, or wish we had). I'm not interested in proprietary add-ons or derivatives of Apache, although if you have to extend a web server, Apache is a great choice. I just don't need to.
Reasons I would leave Apache: none.
Server: Debian GNU/Linux. I've tried RedHat, Mandrake, Gentoo, and FreeBSD, but the fanatical devotion of the Debian package maintainers makes the difference.
Reasons I would leave Debian: stopped being maintained.
Of course, there are also a wide variety of things for which I have no strong allegiance to one tool over another.
hacksrus.com. And with a tilde in the URL to boot!)The release makes a significant change: if XML parsing fails due to character encoding problems, the parser will attempt to auto-determine the character encoding and re-parse with a real XML parser. This is noted in the results as results['bozo'] = 1 and results['bozo_exception'] = feedparser.CharacterEncodingOverride. results['encoding'] will contain the encoding that was actually used to parse the feed (not the original declared encoding).
This release makes another significant change: Unicode support for ill-formed feeds. All individual data values will be returned as Unicode strings if they can be converted using the document's character encoding. I had a flash of insight and suddenly the entirety of Python's Unicode support became clear to me. I coded madly for several hours until it faded. It's entirely possible that that's just the LSD talking, but thanks to the magic of open source, everyone can now share in my good trip.
This release also makes significant changes to internal classes. If you were subclassing or accessing these classes, your code will likely break. If you were just using the public parse() function, you will not notice any change.
My change reporting history has been lax throughout the 3.0 beta process, so I went back and recreated it from file timestamps, comments, and judicious use of diff. Full user documentation is coming next.