dsandler.org/wp

I can’t believe I missed the Slashdot thread on RSS popularity, bandwidth, etc. on Wednesday of last week.

The discussion even veered into p2p territory several times. (Of course, the /. community seems to equate “peer-to-peer” with BitTorrent because that’s all they’re really familiar with, despite the fact that BT isn’t really tuned for this task.)

Oh, yeah, now I remember why I missed this. The article was on Wednesday, and every class of my first semester of grad school had its final project due the next day, for all the marbles. Stupid grad school!

Chris DeSalvo points out that RSS bandwidth requirements hurt clients, too, especially when those clients are bandwidth-limited (by rate, cost, or both). His example (natch) is the Danger HipTop. Which, of course, makes me wonder what kind of mindblowing apps you could build on the HipTop if you could sneak a p2p overlay onto it. [It’s not out of the question, either, since the HT is a Java device (well, J2ME anyway).]

Remember, peer-to-peer isn’t just about file sharing; perhaps most interestingly for mobile devices, group messaging (self-organizing, scalable multicast). The possibilities are endless!

OK, RSS, I love you. But it has to be said: you suck.

Regularly. By design.

Not that there aren’t already enough acronym expansions for RSS out there, but you could call it “Regular Sucking Schedule”. If you’re Glenn Fleishman, you’re the first to do so, and you just set up a new blog to track solutions to the RSS scalability situation.

Despite what appears to be a scathing critique of Glenn’s server-side once-only throttling mechanism, I actually like the spirit of it: It is a serious attempt to force constraints on the system on the server end, rather than a polite request for clients to be better citizens.

Read the rest of this entry »

I’ve been too busy until now to really play with Desktop Manager (a virtual-desktop—or workspaces, or whatever you want to call it—implementation for Mac OS X). I gave up on workspaces when I first started using OS X, since there were (for a very long time!) no satisfactory implementations (and I was too lazy to write my own). Apple clearly feels that the solution to window clutter is Exposé, and while I agree in theory that Exposé is pretty cool, in practice I really haven’t gotten into it. I think what’s most frustrating about it (to me) is that it’s Fifty-Two Pickup with your windows: you still have to perform a visual search of the screen to find the window you want. (To make matters worse, most windows look pretty much like every other window: black text on white, or white text on black, or some slight variant.) I guess I just crave more structure in my window-search system.

So, back to Desktop Manager. It works, it’s fast, it’s pretty. Sold! There are a few twiddly features I’d like, such as more control over the desktop-name display, but that’s eye candy that I can hack into the code if I’m feeling really bored. Here’s a cute non-invasive hack that works with the codebase right now: slick numbers attached to desktop names, thanks to Unicode.

1. Open the Desktop Manager prefs; go to the Desktops tab.
2. Choose Show Character Palette from your keyboard menu. (You do have the keyboard menu showing, don’t you? If not, turn it on from the International pref pane.)
3. Be sure you’re viewing unicode blocks in the char palette, and scroll down to (and select) Dingbats. You’ll see some lovely sans-serif white numerals on black circles.
4. For each desktop (back in the Desktop Manager prefs), double-click its name to edit it, place the cursor at the beginning of the name, and then double-click the corresponding numeral in the Character Palette.

Now you have a nice, easily-visible numeral in the corner of your desktop (and in the pop-up while switching desktops).

Since last month, when I wrote about Glenn Fleishman’s RSS figures, Glenn has come up with a rudimentary solution:

I built a simple program running via Apache that throttles RSS downloads: a given IP and user agent combination can only request a given RSS feed file if it’s changed since they last retrieved it.

He argues that this solution worked for him. It’s hard to tell from his daily RSS bar-chart whether the solution (deployed on 11/20) is responsible for the decrease in RSS bandwidth (which seems to start a couple of days before that), but what concerns me most about this solution is that it requires per-client state to be maintained on the server.

I’m uncomfortable with this solution because it’s hard to make it scale. First, you have to hit a database (of some kind) to cross-reference the client IP address with its last fetch time. Maybe that’s not a big deal; after all, you’re hitting the database to read your website data too. But then you have to write to the database in order to record the new fetch time (if the RSS feed has changed), and database writes are slow.

The other obvious problem with this approach is that IP address (well, IP address combined with User-Agent) is no good for hosts hidden by address translation. Actually, I don’t think the User-Agent string helps much at all, since hosts behind NATs (home computers, office computers) tend to have homogenous software environments and are therefore likely to have identical UAs. So that means only one user behind a NAT is able to get each new RSS item. (Not one at a time: one, period. Until the RSS changes again, and then it’s a race to see who can snag the file first.) [Update: Dann Sheridan experiences this exact problem.]