azz:
This is a pretty neat bit of software. It's an Emacs-style chrome for Mozilla.
I'm tempted to try to customise it to have Links keybindings, since the Emacs ones are a bit clumsy, but it does work pretty well as is.
It'd be nice if it had a tab display; like with Emacs, it's not obvious what buffers you've got open.
azz:
The BBC have made back issues of the BBC Engineering journal available, and they're quite interesting reading.
This one's from April 1977, and has an article called "The Nature of Broadcasting" which summarises all the stuff the BBC was working on back then.
The bit starting on page 13 about satellite broadcasting is especially interesting: the author concludes that just having more channels wouldn't sell satellite broadcasting very effectively, but HDTV would. He also predicts compressed video, although since this is the pre-digital age the description's slightly unusual (and the bandwidth he thinks necessary is huge by today's standards).
There's also a bit earlier about the BBC's forerunner to RDS.
azz: "In a nutshell, based on the ETag that the client sends, the server can determine which entries the client has already seen, and can save bandwidth and perhaps even some client processing if only those entries that have changed are sent back."
Arghhh.
This'd explain some of the odd behaviour I've been seeing with some feeds in rawdog, which applies precisely the same rule that Planet does...
My gut reaction is that this "RFC 3229 + feed" thing is an utterly stupid and broken design. I'm now wondering how on earth I'm supposed to tell when an article's been removed from a feed.
The status code thing is of no help whatsoever, since presumably I'll always get that status code back if I send an ETag.
I guess one option is to disable ETag support, but I'd rather not do that (and presumably people will pull the same stupid trick with If-Modified-Since)...
Oh, and look, the code to send the magic header in the request got added to feedparser with no mention in the documentation, and no actual handling for the different response code that it'll give you. Mark Pilgrim screws me again.
Presumably the idea is that if you've removed items from the feed, then you effectively invalidate all the ETags you've issued and just start returning the whole feed again with a new ETag. I don't think the sample code for intertwingly.net does that, though -- it looks like it only checks for new items, not removed ones.
I think the major problem I've got with this "RFC 3229 + feed" design is that it's a layer violation. HTTP should be about pushing chunks of bytes around; the data-transferring layer shouldn't need to be aware of the format of the data. I should be able to use a tool that doesn't know anything about feeds to download a feed. This proposal breaks that.
I don't see how it buys you anything over doing byte-oriented deltas, which are easy to implement in a generic way. Imagine how messy it'd be if every file format invented their own delta mechanism -- there's nothing special about feeds.
Well, anyway, I've instrumented my rawdog so it should tell me if any feeds I'm subscribed to are using it; I'll see about getting a fixed version out in a couple of days.