Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!cunyvm!nyser!cmx!goedel!chris
From: chris@goedel.uucp (Chris White)
Newsgroups: comp.windows.news
Subject: Re: NeWS applications should not depend on file access on the server
Message-ID: <1624@cmx.npac.syr.edu>
Date: 2 Jun 89 15:10:39 GMT
References: <7506@hoptoad.uucp>
Sender: usenet@cmx.npac.syr.edu
Reply-To: chris@logiclab.cis.syr.edu (Chris White)
Organization: Logic Lab, CIS Dept., Syracuse University
Lines: 46

In article <7506@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>I have seen a number of applications, from Sun's supplied psterm and
>scrolldemo, to GoodNeWS, which load in files on the machine running
>the NeWS server, regardless of where the client program was run from.
>
>This causes a variety of problems...

I ran into this problem with my user interface resource file editor
(FaceKit).  It's written entirely in NeWS, and resides in the server.
The problem is that it currently MUST load files from the server-side.
That's because it is not a C/PostScript program -- it is a PostScript
program.  I would like to load files from the client-side, but I don't
want to be forced to write the facilities for communication between C and
PostScript for every (possibly small) program I write that reads in files.

>
>The solution is fairly obvious -- EVERYTHING required by the PostScript
>side of an application must be uploaded from the client side over the
>network socket.  All the PostScript code.  All the image files.  All
>the custom fonts.  All the everything.

I agree with you in a sense. But I think that somebody other than the
application programmer should be responsible for providing adequate
facilities for doing client-side file loading from a server-side NeWS
program. I envision a client-side daemon that handles file operations
(among possible other things). The client-daemon interface should be
written so that most of the current programs will work. For example, if
I execute:

    (resource.ps) run

in a NeWS fragment, a message will be sent acrossed a socket to the
client-side daemon telling it to find the file resource.ps, and pipe
it back so it can be executed.

This doesn't solve the relative pathname problem, though. That could be
solved by having the convention that certain environmental information
is always passed to the NeWS server. In most cases, this would be
automatically done by cps or psh. Useful information would include the
current directory (the directory the user was in when they ran the
application) and the program directory (the directory the program resides
in).

                -- chris white

"The solution to making NeWS successful is to make it illegal."