browser execution

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Tony Sanders: "Re: browser execution "
• Previous message: Terry Allen: "One PRE, and entities"

Date: 27 Jun 93 20:53 -0700
From: George Phillips <phillips@cs.ubc.ca>
To: <www-talk@nxoc01.cern.ch>
Message-id: <5886*phillips@cs.ubc.ca>
Subject: browser execution

I've thought about this business of getting a WWW browser to execute
a program and I've convinced that a new URL scheme is necessary
for some uses.  In particular, you need it if you want to repeatedly
run a program which outputs HTML (or MIME) and generally acts like
a server.

An executable MIME content type is good for "one-shot" executions
(like a "mail developers" link which runs a mailer), but it can't
cover the more dynamic semi-server case.  Why?  Because you need
a MIME document to back up each URL your server outputs that
refers back to the server.  This is fine with an HTTP server, but
for a browser-executed server it means having a file for every
link which defeats the purpose.

A hack to the file: scheme is mostly OK except that it limits executable
things to file: (no big deal with the MIME executable content type),
is not particularly abstract (it points to a specific file) and leaves
the relative URL semantics hanging.  Look at the HTML output of
file:/bin/rn.html%/comp/sources/misc.  If it outputs the anchor
<A HREF=/comp/binaries/mac>mac</A>, does that mean
file:/comp/binaries/mac or file:/bin/rn.html%/comp/sources/mac?
The writer of "rn.html" would certainly prefer the latter over
having to constantly spit out full references, but the former is
what should really happen.  Sure, we could pass in the full URL
to rn.html so it knows the path, but that seems pretty messy.

So how about this:  an "exec:" scheme that looks like:

	exec://encoded-URL/opaque/stuff/like/other/URLs

Semantics: decode the "encoded-URL", grab it and execute it
with the rest of the URL.  I used the  "//" notation so
that executables can ouput "/" rooted URLs without having
to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
We can do the "encoded-URL" any way we like, but suppose that
: -> ; and / -> \.  A full exec: URL might look like:

	exec://file;\bin\rn.html/comp/sources/misc

However, with the MIME executable content type, I'd expect that
most exec: URLs would point to files, so file: would be the default.
Additionally, the browser might have some notion of a PATH for
exec: files (possibly as a first-level security mechanism), so the
whole thing could be shortened to:

	exec://rn.html/comp/sources/misc

I fully realize that these URLs probably won't work between different
sites.  I don't expect WWW servers to be sending you these any time
soon (unless they're trying to delete all your files :-), but
it's possible if some general agreement on the symbolic names
happens.  For instance, it may become agreed that
<A HREF=exec://mailer/mosaic-guys@ncsa>bug report</A> will
fire up some kind of mail program.

While the file: with %/ hack is workable, I think this is better.
What do you think?