Re: Annoucement: Local Browser Execution
marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Tue, 14 Dec 93 00:36:32 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9312140836.AA05769@wintermute.ncsa.uiuc.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Annoucement: Local Browser Execution
In-reply-to: <199312140552.XAA02630@austin.BSDI.COM>
References: <199312140552.XAA02630@austin.BSDI.COM>
Tony Sanders writes:
> > I've been working on a new URL scheme called "x-exec:" which directs
> ...
> > One last thing. I'm certainly interested in discussing viable
> > alternatives to x-exec: and suggestions for improving it. Flames
> > about it being "a bad thing" and/or "the wrong thing" will be
> > accepted in the same cheerful spirit as Mosaic Motif flames.
>
> Ok, define a content type application/x-exec that returns some data for
> you to deal with. This doesn't require *ANY* changes to the browser and
> at some point down the road you will be able to authenticate the data
> instead of being forced to trust just anyone. Same effect, much more
> flexible, and it doesn't clutter the URL space.
>
> --sanders
George and Tony --
What if there were an attribute to given MIME types, specifiable in
one's .mailcap, called "receiveoutput" or something similar? This
would be similar to how mailcaps are also supposed to be able to
supports "needsterminal" attributes and the like. E.g.:
application/x-csh-exec; my-csh-exec %s; receiveoutput
When the browser fetches a data object of type application/x-csh-exec
it runs my-csh-exec and, due to the presence of "receiveoutput", pulls
the output of my-csh-exec back into the browser as an HTTP/1.0
object...
What am I missing (i.e. what do you want to do with x-exec that that
wouldn't support)?
Cheers,
Marc