Re: Annoucement: Local Browser Execution
hgs@research.att.com (Henning G. Schulzrinne)
Message-id: <9312151304.AA13944@dxmint.cern.ch>
Date: Wed, 15 Dec 93 08:03:46 EST
From: hgs@research.att.com (Henning G. Schulzrinne)
To: phillips@cs.ubc.ca, masinter@parc.xerox.com
Subject: Re: Annoucement: Local Browser Execution
Cc: www-talk@nxoc01.cern.ch
> From research!dxcern.cern.ch!www-talk-request Wed Dec 15 05:16:12 1993
> To: phillips@cs.ubc.ca
>
> I think x-exec: is an ugly hack. I'm about to propose something that
> at first glance looks like an uglier hack, but maybe after you think
> about it for a bit you won't shoot me:
>
> Right now, you're taking something 'x-exec:blah blah' and treating it
> as a URL that executes something special.
>
> Why not, instead of searching for "x-exec:", search for
> "http://cs.ubc.ca/exec/". That is, build *into your client* the
> special case that if you see "http://cs.ucb.ca/exec/blah blah",
> instead of sending http protocol somewhere, you execute "blah blah" as
> a shell command.
I believe this solution to be far superior. One of the nicer things
about URLs is that you don't necessarily know or care whether something
returned to you has been generated dynamically or exists as a file.
Conceptually, both are the same: In either case, you provide a
string that maps into some output, to be returned. For file retrieval,
the mapping is done by the filesystem, for a shell command it is done
by some special program. You might even decide to switch between the
two, e.g., if the range of arguments provided is small enough that
they can easily be mapped into files.
Henning
---
Henning Schulzrinne (hgs@research.att.com)
AT&T Bell Laboratories (MH 2A-244)
600 Mountain Ave; Murray Hill, NJ 07974
phone: +1 908 582-2262; fax: +1 908 582-5809