🚀 go-pugleaf

On Thu, 29 Jul 2004 10:16:17 -0700, Bob Gonder 
   <notbg@notmindspring.invalid> wrote:

> Hans Galema wrote:
> 
>>That would have made things inconsequent. http:// invokes communication
>>with a webserver. Where a -local-file:// has to be grabbed by the browser
>>itself. Quite different.
> 
> If you fire up I.E. and enter a URL from the address bar, you don't
> type in the http: or file:, just the URL, and it decides where that
> resides.  Why should starting it with a commandline be any different?

Because the application is already running, and can interpret its
user input however it wants.  For instance I have one browser which
systematically tries adding www. to the front, .com, .org etc. to the
end, until it finds something which works.  That sort of thing is up to
a program to do (some may want to try opening as a file first, others as
a web page first, or whatever).

Programming interfaces are dumb.  If I say fopen("fred", "r"), it won't
look for fred.html, fred.htm, fred/index.html, http:/www.fred.com/ or
anything else, it will look for a file called fred in its current
directory.  If the programmer wants anything else, they can write it.

> Why should the programmer interface be dumber than the user interface?

Because the programming interface needs to do what the programmer wants,
and nothing more.  If I tell it to run "fred.com", it will assume that I
mean the file of that name.  If the file doesn't exist (or isn't
executable) then it will return an error, and the program can then
decide what to do (it probably wants to give the user an indication of
error, for most purposes; only a browser would assume that it meant an
internet address, and that would probably assume web access as the first
option).

If I type "fred.com" into IE, it will look for a web site with that
name.  If I mean that it should open a file of that name, I have to tell
it explicitly (or use an editor or some other program).  It's a program
(and programmer) decision.

Chris C