Re: sending Brian Behlendorf ([email protected])
Fri, 16 Jun 1995 15:12:56 -0700 (PDT)

On Fri, 16 Jun 1995, Anthropohedron wrote:
> Eventually,
> encapsulated into a helper app, like images or sound or video, should be in
> the helper app. If the helper app would have to communicate with the
> browser then it is not encapsulated and should be a part of the single
> browser. The browser becomes a monster app, but this Webspace-Netscape
> communication is a nasty kludge (which, I might add, breaks when using any
> window manager except 4Dwm on an SGI) and the
> more memory and more disk space than an integrated viewer, not to m>ntion
> the debatable inconvenience of two windows rather than just one. Note that
> if you are going after two VRML pages in two separate Netscape windows,
> whether one was spawned from the other or they are >ntirely separate
> processes
> first one to finish receiving a VRML file
> tells
> behavior.

This is true, but until there is more modularity in the something we'll have to live with. Right now there are orthogonal applications rolled into the "web browser":

Protocol handlers (HTTP, gopher, ftp, news, etc)
Data renderers (HTML, images, in some browsers SGML and PDF)
History/Navigation mechanisms (Hotlists, etc)
Caching

The first company to separate these out into separate modules on an
integrated desktop will get my undying respect. For example on Windows there
should be an HTTP.DLL which all data renderers can utilize when they need to
realize a URL. That way there wouldn't be a distinction between
webspace's HTTP transactions and netscape's HTTP transactions, and one
wouldn't have to touch the other. The situation where the data renderer
for one data type realizes a URL that returns data for a different
renderer shouldn't be all that hard to handle in this situation.

> What I would expect to see and would like to promote is the
> multipart/mixed subtype to combine VRML with HTML. It is not even
> unreasonable to hack a server (I will concern myself with NCSA, since I
> don't know any other well) to recognize another variable in the
> say VRMLRoot or VRdocRoot, that would give a directory with a parallel
> directory tree under it containing
> that Docum>nRoot is set to /usr/local/etc/httpd/htdocs and VRdocRoot is set
> to /usr/local/etc/httpd/vrdocs. Then, when the server got a request for
> perhaps /neato/spiffy/wheretogo.html, it would make
> /usr/local/etc/httpd/htdocs/neato/spiffy/wheretogo.html the first part of a
> multipart/mixed MIME

  • of Content-Type text/html and
    > usr/local/etc/httpd/vrdocs/neato/spiffy/wheretogo.wrl the
    > Content-Type x-world/x-vrml.

    Hmm... I thinknt<
    they indicated they would prefer the most, and give some indication when<
    that docum>nt more than one object per HTTP transaction (even sending were not explictely asked for but the server "anticipates" thent<
    might want, like inlined images on an HTML page or textures for a VRML
    object) will be a property of HTTP-NG and to a more HTTP-1.1.

    > The solutions to these
    > HTTP_ACCEPT properly so
    > only accept type for which there is a mailcap >ntry (i.e. if you can't view
    > VRML, don't put an x-world/x-vrml >ntry in the
    > won't HTTP_ACCEPT it) and have the server process the HTTP_ACCEPT
    > intelligently to send one format or the other or both depending
    > accepted; Second, put multipart handling into the WWW browsers (hint, hint
    > to Netscape, NCSA, Spry, Win-/MacWeb, etc.)! Both of these solutions should
    > not be necessary, since had the HTTP and MIME
    > would already be implelinted.

    Yep, MIME.DLL would be another good orthogonal piece :)

    Brian

    --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
    [email protected] [email protected] http://www.[hyperreal,organic].com/