Saturday, August 09, 2003

The Economics of Application Installation Comment [] • Trackback [] • Google It! • 10:54:41 PM • Sean McGrath writes in ITWorld: In my mind's eye, I see an installation system based on Unix's chroot concept (for establishing virtual hierarchies for applications) and Unix's symbolic link concept (for managed duplication). I see a world in which every Java application has its own JVM, its own JDK, its own copy of *everything* all in a nice tidy directory - a truly self contained world. Why not? It would waste a few gigabytes? In the time it has taken you to read this article you have probably been paid the equivalent of many gigabytes of disk space. The sad reality is that as CPUs are getting faster, main memory and disks lag behind. By a long shot. So, if each application you have installed duplicates all the libraries it depends on, it will take longer to install, longer to load, and (because modern CPUs totally rely on their cache to keep their maximum pace) longer to execute. The assumption that we should stop optimizing for size, popular as it is among dynamic languages supporters, is plain wrong. Actually, it's getting to be farther from the truth as CPUs keep getting faster, but memories and disks don't.

URI != URL Comment [] • Trackback [] • Google It! • 9:21:16 AM • In a comment to my post on Atom 0.2, Sam notes that the <link> element is a URI, not a URL. Thanks, Sam, I didn't notice it. Now that I have, it looks wrong to me. There's a tendency in our industry to treat URIs and URLs as if they're the same thing, or at least very similar. There's also a common thinking that "a URI is everything a URL is, only a bit more general, so let's use that instead". I agree with neither. On the Difference of URIs and URLs To explain why, here are the two important differences between URIs and URLs: A URI represents identity. As such, a resource's URI doesn't change. A URL, on the other hand, is a name. Just like people can change their name, the name(s) of a resource may change. A resource's URI tells you nothing about the resource. It's URL gives you a closure of actions you can apply to it. (For example, if you have a http: URL, you can do GET, PUT, POST, etc; if you have a mailto: URL, you can send mail to the resource, etc.). The point is that while these differences make little difference to us humans, tools that process them (should) behave differently. If U is declared to be a URI, a tool that processes it cannot in general apply any action to U. (There was a long discussion in the XML circles about what would you find at the "end" of namespace URIs when they are URLs; as far as I know, the proposal I most liked -- RDDL -- never got anywhere.) When U is declared to be a URL, the tool can in general rely on its semantics beforehand, for example try to retrieve it for offline reading. (This applies to URLs whose protocol has some "GET" action, like http:; this isn't the case for mailto:, for example.) Even if the tool does not understand the semantics of the URL, it can still offer a hyperlink to it (punting the work to the OS, if you're working in Windows). <link> Should be a URL Coming back to the original issue, a <link> element serves human readers, because tools cannot rely on the resource it represents to mean anything. As such, making <link> a URI makes little sense to me: what is the utility of allowing a <link> to be "bla:1234.0987"?

© Copyright 2003 Ziv Caspi.