Re: Linking PC network resources thru HTML

Paul Wilson (
Thu, 26 Jan 1995 16:16:58 +0100

On 1/26/95, Howard Amos wrote:
>I'm working on linking some PC network resources through HTML links and
>would like to know the best way to go about referencing these network
>What I thought of doing was writing a DOS batch file to neatly access the
>resource, but I need some way of getting my Web browser to understand that
>the appropriate link is not going to a text document but should execute a
>program/batch file instead. At the most basic level, I need to shell out
>from my browser to DOS (I'm using Netscape for Windows).
>Is this just a fanciful idea that really should be implemented, or is there
>anyway to do this sort of thing?

I have been working on a similar idea for a client of mine.

We are interested in having a feature that allows a user to move
interchangeably between the WWW and the local disk(s). This is trivial for
HTML files or documents, but for running scripts (search engines, imagemap)
or parsing forms, there is not current method. One option which to me seems
non-ideal is to run a server in a loopback kind of mode on the local machine.

My idea as to how this might be implemented would be a new type of URL:
exec:// --- for remote scripts
exec://scriptname --- for local scripts

This would essentially (but wouldn't have to) do away with the cgi-bin
directory and allow users to place scripts where they liked.

Unforunately this seems to break with convention that a URL type represents
a unique and singular transfer protocol. This implementation would require
"exec" to use http when functioning remotely. Obviously for local scripts,
some shell like functionality would have to be built in to the browsers.

The clear advantage of this is the ability to take entire hierarchies of WWW
server data, cgi-scripts, databases and/or search engines and burn them onto
CD-ROMs (for example) and then access them locally. While the limited
bandwidth of todays networks makes that a useful application now, future
applications might include self contained kiosk units, etc.

I envision mainly two counter arguements.
1) As the bandwidth increases, as it will, there will be no need for
distributing data on fixed media, but instead, everyone will just get what
they want over the network.
RESPONSE: That bandwidth availability is not currently in place, and
probably is far enough away that valuable use will result from this
alternative. Furthermore, there may always be situations where people want
to take data "on the road" with them, perhaps even to places where the
network has not yet reached.

2) Why not write proprietary viewing software for your database or hierarchy
which allows you to run local scripts?
RESPONSE: Building into a URL allow the browser to seemlessly go from the
local machine to the network and back without quitting one application and
starting another. It also allows the same authoring conventions to be used
when constructing the local information so that portability and use by
others is straightforward.

Paul Wilson (608) 265-4573
Trace R&D Center