Re: browser execution

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Errors-To: sanders@bsdi.com
Message-id: <9306280535.AA27645@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: browser execution 
In-Reply-To: Your message of 27 Jun 93 20:53:00 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Mon, 28 Jun 1993 00:35:06 -0500
From: Tony Sanders <sanders@bsdi.com>

> 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.
SAS strikes again (server aversion syndrome :-)

FYI: Here is how using content-type might work for your example of a
pseudo-newsreader (using a server of course).

    <A HREF="http://server/rn.html">drink me</A>

on selection returns the document:

    content-type: application/x-csh
    ... whatever you wanted rn.html to do
    ... links can look like <A HREF="http://server/article/####">read me</A>

http://server/article/#### returns:

    content-type: application/x-csh
    ... whatever you wanted rn.html to do with the #### argument

So I argue we should figure out to have the browser talk to a local server
rather than figure out how to encode arbitary commands in the URL.

My reasoning:
  o Browsers cannot change on a whim, because for the Web to be truly
    useful to the user community at large all browsers must support the
    **same** set of features (to a large extent anyway).
  o Therefore we **must** have a definition for the browser that is simple
    and complete such that any features you might ever want can be done
    in a server.

    So why the SAS that seems to be so prevalent?  Instead of hacking
    things into the browser we should be looking for ways to extend the
    browser such that servers can do those tasks, but everyone seems to
    be heading the opposite direction.  Maybe this is something we
    can take up at the workshop (what should go in the server and what
    should we build-in to the browser).

I'm not a purist or anything, I think it's fine if we want the browser to
support things like gopher and ftp directly but at some point we are going
to have to draw the line if we want most browsers to support a common
set of features (even <IMG> is a good example of this problem).

--sanders