What I find problematic about this approach is that it leads to an implementation that represents the least common denominator. Protocols that have some conceptual overlap were devised for a reason and represent some sort of evolution. Treating them all the same is, to a certain extent, nullifying this evolutionary aspect.

FTP, Gopher and HTTP are related in a way where it doesn't hurt too much if a HTTP client also support Gopher and FTP. However, there are cases where this doesn't work out so well (E.g. cross platform GUI frameworks).

Consequently, I'd say that it is nice to provide a unified interface for conceptually related technologies. On the other hand, I'd be really careful about overplaying this sort of design principle where it may lead to sub-optimal or overly complex solutions, simply for the sake of supporting more technologies (who needs Gopher these days?)

Any idea how old this is? It mentions Gopher ... Just the fact that it's some kind of technical writeup by jwz means it has to be a bit dated, right?

http://bonsai-www.mozilla.org/cvslog.cgi?file=mozilla-org/ht... indicates it dates from '98

Yet I can't use chrome for basic FTP access. I have to use Firefox (or could use IE.) So if this is old, the message is not necessarily dated.

This is why Emacs-lovers love Emacs.