gnu@hoptoad.uucp (John Gilmore) (06/02/89)
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. The most obvious is that such a
program doesn't work unless it is installed on both the server and the client.
If you go to someone else's NeWS screen and run the client, it dies.
If you try to demo it to a colleague while visiting some other University,
it dies. If you reinstall the NeWS server directories, it dies. Etc.
Another problem is that users will specify file names to this kind of
command, expecting the files to be referenced with regard to the current
directory and host machine on which they are running the command. Instead
the files are relative to the directory that NeWS was started in on
the server machine. I had this bite me when I modified "scrolldemo"
to be able to show any file, not just those compiled in to it.
It also makes these applications fail to run on "NeWS terminals" (I like
the term "newts", which someone proposed here on News-makers.) Hugh Daniel
pointed out this problem more than a year ago when he was working on
the now-dead MacOS NeWS port for Wedge, which didn't have a Unix file
system behind it.
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. It's not hard -- at Grasshopper
we spent more time arguing over it, than we did implementing it in
psterm. And there is no evidence that it's slower than reading from
the server's file system -- though even if it was, you can't start
optimizing until you first make it work! And it doesn't work if you
have to customize the server.
I recommend that the words used for local file access (forkunix,
readcanvas, file, loadfile, writescreen, etc) be moved out of
systemdict and into a private dictionary. Dummy versions that will
only operate on sockets or %stdin or %stdout or %stderr could be put in
systemdict to catch thse poor practices and diagnose them. PostScript
code such as init.ps that really needs to do this, can run the words
from the private dict.
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.chris@goedel.uucp (Chris White) (06/02/89)
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."
prove@batcomputer.tn.cornell.edu (Roger Ove) (06/03/89)
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. The most obvious is that such a > program doesn't work unless it is installed on both the server and the client. > If you go to someone else's NeWS screen and run the client, it dies. > If you try to demo it to a colleague while visiting some other University, > it dies. If you reinstall the NeWS server directories, it dies. Etc. The only problem with this is that in slow bandwidth situations it can take a long time to download the postscript. It should be possible to get around this by downloading a small bit of ps first to check on the file's existence, and on failure download the rest of the ps. I tried to implement this and failed, seemingly due to a NeWS bug. Putting the file load in a {...open file ...} stopped clause ought to do the trick, but it bombs out anyway when it can't find the file. I guess I'm not the only one that has run into this problem, since the routine /fileexists in the default init.ps is commented out. Has anyone found a way to make this work? Anyway, if this worked then users interested in faster response could obtain the resident front end, and you could still demo the application (with excuses) without it. I agree that counting on the existence of files should be discouraged, and seems contrary to the spirit of NeWS. Roger Ove ove@ncsa.uiuc.edu
arthur@turing.ac.uk (Arthur van Hoff) (06/05/89)
Hi there, Some remarks have been made on the file usage of GoodNeWS applications. It is true that for standard applications it is NOT a good idea to load a PostScript file using the server. There are some situations where it is forgivable: - If the file is part of a standard interface and therefore has to be available to the server anyway. - If the application is entirly written in PostScript. - If you are using a low-bandwidth connection. Here is your own responsibillity to make sure that the remote server will be able to access the file. One problem remains. You need to specify a full-pathname when a file is loaded from the server. This is caused by the fact that the server may have a different current-directory than the application. In GoodNeWS/HyperNeWS (where most applications are entirely PostScript based) a simple but not very effective solution was used. A routine called "ExtendFileName" was implemented which attempts to open a file by searching a number of directories depending on the file extension. This allows you to store a set of PostScript files in library directories which can be loaded without specifying a full pathname. For example: (test.draw) ExtendFileName ---> (/usr/arthur/draw/tmp.draw) (~/help/text.1) ExtendFileName ---> (usr/arthur/help/text.1) (arthur.img) ExtendFileName ---> (/usr/local/GoodNeWS1.2/img/arthur.img) At the moment the list of directories which are searched is fixed. A good idea would be to specify a list of directories using an environment variable. Arthur van Hoff