Does anyone have a recommendation for a good hobby shop anywhere in the Mountain View, California area, particularly for model railroading? I live two blocks from the San Antonio Hobby Shop, but I like it less each time I visit. First, what kind of hobby shop is closed on Sunday? Second, they have impressive square footage, but never seem to have what I’m looking for. Third, the attitude of the stuff leaves a lot to be desired. They always make me feel like I should go away and stop thinking about visiting their store (which is easy, because they’re usually closed when I think about it).

My pants pocket has developed a small hole, and throughout the day coins have been falling out of my pant leg as I walk. On my way home, I discovered a penny at the bottom of my sock. That’s just strange.

Curtis recently wrote:

As the world moves to HDTV and 16:9 widescreen displays, people will still want to watch older programs– reruns of Star Trek, for example, which were created for 4:3 displays. Why not use the blank space on the sides of the screen to display ads?

Interesting idea, but it reminded me of something I’ve wondered about every since I first read the HDTV draft standard published by ATSC five years ago: Why are the high-definition resolutions (e.g., 720p and 1080i) not available in the 4:3 formats, and what will that mean for archival content?

I understand that widescreen is the Television of the Future, and I suspect that the reason that HDTV is widescreen-only was to encourage the switch to widescreen by both set manufacturers and content providers (i.e., networks and studios). The 4:3 “square” aspect ratio has long been considered inferior, and Hollywood has been trying to get us to use widescreen TVs for years. It doesn’t appear to have worked; I notice that consumer electronics stores are happily selling 4:3 HDTVs, although I admit I don’t know what they do when presented with actual HDTV (hence 16:9) content; I imagine they letterbox it, although they might have a zoom mode that chops off the sides.

But besides new content, there’s plenty of old 4:3 television episodes and movies that are ripe for high-definition conversion. Curtis’s example, Star Trek, was filmed and edited on 35mm film, and might benefit from an HD version (actually, it might not; it was shot for television, and adding extra detail might reveal that the costumes, props, sets and makeup was never intended to be seen that close up). But there’s no good way to broadcast it on HDTV without windowboxing—adding black bars to the sides—or cutting off the top and bottom. Which is, I guess, fine if you have a widescreen TV, but if you have a 4:3 HDTV (as mentioned above), what you end up with is a black box around an image that only takes up two-thirds of your TV. Even if you zoom in, you’ve lost a third of the resolution HDTV promises. It just doesn’t seem right.

I recently read through this thread from the IETF HTTP working group, circa 1995, on Netscape’s then-current proposal to add byte-range support to HTTP. What I found fascinating about the thread is that at the time, there was great resistance to the idea. Netscape wanted support mainly so they could retrieve individual pages of embedded PDF documents, but many people objected that general byte range support was too expensive and complex to support this one use, and that byte ranges were the wrong mechanism for this anyway (which is true).

What’s amazing is that while the resumption of interrupted documents—which is probably what 99% of byte range requests are used for today—was mentioned as a potential use (and Netscape Navigator 2.0 did implement it), no one seemed to consider it a worthy goal. Many people pointed out that a lot of documents (server-translated HTML, CGI scripts, etc) could not be reliably byte-served, or would be prohibitively expensive to do so. Static binary files were mentioned, but mostly in the context of, e.g., a 100k image, where it would be a handy convenience rather than a huge time-saver.

It is remarkable today to remember that in the mid-’90s, HTTP simply wasn’t considered a viable way to transfer files. If you wanted to download a large file, you switched to FTP. Nine years later, of course, I find myself routinely using HTTP to transfer multi-gigabyte files, for which the possibility of resuming a failed transfer without starting over is much appreciated.

I also noted with satisfaction that it was my idea to encode the range request in a request header, which is the design that ended up in HTTP 1.1.

What’s the point of an ATM if not to dispense cash? More seriously, given that 99% of ATM transactions are cash withdrawals, why wait until the customer has inserted their card, entered their PIN, selected their transaction type, and entered an amount before mentioning that there’s no money to be had? A clever ATM design would flash “NO CASH TODAY” in big red letters before you even insert your card.

My Web site is now at my shiny, brand-new domain name. My weblog’s new address is http://akosut.com/log/. Thanks for visiting.