sending VRML or HTML based on viewer

The way one is *supposed* to know what a client can process i HTTP_ACCEPT field that the client should be sending to the server. Note
that Webspace does not bother to send thi <(hint, hint to TGS and SGI).

} Mosaic caches recently accessed files and for
} the conventionally small documents, that is fine.

I am not sure what caching has to do with the other stuff. Do you mean that
these "cooperative peer apps" (see below) should be able to use (read/write)
the WWW browser's cache?

} What happens if cooperative peer apps are
} downloaded (aka, push and pull)? It would
} seem that these apps which define in
} external or internal scripts more sophisticated
} transactions could be problematic. does

I'm not sure why you are using the terms push and pull. The only connection
I can make is Netscape's server push multipart/x-mixed-replace MIME subtype
for server push and their HTML <META> tag for client pull (see
<http://home.netscape.com/assist/net_sites/pushpull.html> for more info on
thi

When you say cooperative peer apps rather than helper apps I assume you are
speaking of a VRML viewer like Webspace. I don't know of any app called from a WWW browser that

} the MIME mail approach start to break here,
} or is there a } what support capacity i } any } particularly if they invoke apps for
} multiple notations?

I don't know what you mean by multiple notations here. The mechanism for
indicating what a client supports i for.

When it comes to actually deciding whether to send VRML or HTML from a site
(assuming there are parallel HTML and VRML pages for essentially everything),
the HTTP_ACCEPT is implemented by any use Webspace (or your favorite VRML viewer) to connect to a site for the
first time and the site, based on the HTTP_USER_AGENT field, can decide to
send VRML. If there Of course, at the moment Webspace does not send any information at do thi

Eventually, however, thi encapsulated into a helper app, like images or sound or video, 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 communication is a nasty kludge (which, I might add, breaks when using any
window manr except 4Dwm on an SGI) and the two together undoubtedly more memory and more disk space than an integrated viewer, not to mention
the debatable inconvenience of two windows rather than just one. Note that
if you are going after two VRML pages in two separate whether one was spawned from the other or they are entirely separate
processes they do not open two separate first one to finish receiving a VRML file opens Webspace and the second
tells that same Webspace to go elsewhere. Hardly intuitive or desirable
behavior.

What I would expect to see and would like to promote is the use of the MIME
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 say VRMLRoot or VRdocRoot, that would give a directory with a parallel
directory tree under it containing VRML files. As an example let's suppose
that DocumenRoot i 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 mi> of Content-Type text/html and
usr/local/etc/httpd/vrdocs/neato/spiffy/wheretogo.wrl the second part of
Content-Type x-world/x-vrml.

I think are 1) bandwidth; this essentially sends much the same information twice,
and 2) I do not know of any types, except Netscape and its own proprietary multipart/x-mixed-replace
subtype (which doesn't seem to like launching external apps, though I have
not done extensive testing).

The solutions to these two problems are fairly simple. First, implement the
HTTP_ACCEPT properly so that VRML viewers only accept VRML and WWW browsers
only accept type for which there VRML, don't put an x-world/x-vrml entry in the mailcap and the browser
won't HTTP_ACCEPT it) and have the server process the HTTP_ACCEPT
intelligently to send one format or the other or both depending on what is
accepted; Second, put multipart handling into the WWW browser <(hint, hint
to Netscape, NCSA, Spry, Win-/MacWeb, etc.)! Both of these solutions should
not be necessary, since had the HTTP and MIME standards been followed they
would already be implemented.

} Len
} Bullard
--Greg