The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern:
selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.
This video is a charming trip down to memory lane to the early days of the public internet:
It wasn’t quite the World Wide Web yet, but everybody started hearing about this thing called “the Internet” in 1993. It was being called the Information Superhighway then.
This is a wonderful deep dive into all the parts of a URL:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
There’s a lot of great DNS stuff about the host part:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:
The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.
This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.
Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.
A deep dive into the history of Gopher. For a while there, it looked like it was going to be bigger than the World Wide Web.
This article is filled with timely details:
The programmers were young guys, mostly in their 20s and, like McCahill, mostly huge Nirvana fans. Paul Lindner, a coding wunderkind from northern Minnesota who was dubbed the Gopher Dude for his evangelism, had long metal-head hair and signed Gopher emails with lyrics like “You have to spit to see the shine” from Babes in Toyland. Early Gopher servers were named Mudhoney, Danzig, and Anthrax.
Ah, Babes In Toyland! It’s like the soundtrack to my time in art college in the early 90s. I remember one of the best gigs ever being a triple bill of The Sultans Of Ping, Babes In Toyland, and Theraphy? at Sir Henrys in Cork.
A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.
And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.
URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.