sjs@spectral.ctt.bellcore.com (Stan Switzer) (06/06/89)
>>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). This is the germ of a very good idea! Logically, in a modeless user interface, it is the user that controls the program, not the program controls the user. To effectively implement such an interface, the server-side code should be able to invoke generic (preferably extensible) facilities from the client side. Currently, there is no mechanism for building general-purpose, reusable, modular, client-side support. Suppose that an application browses two files side-by-side. There should be a way to instantiate two file access objects on the client side and operate them independently. As it is now, the client's main routine must discriminate and demultiplex all traffic between the client and the server. Consequently, the client side cannot merely "attach" a file-access object but must also mediate in the traffic thereafter. Here's a potential mechanism for handling the problem. It is somewhat like the CID mechanism, except that the roles are reversed. It's a pretty rough sketch, but I think you can get the gist of it. The idea is to create a mechanism that allows you to package up a tool with both PostScript and C parts to it in a self-contained, reusable, multi-instance, library-storable components. What is needed is some sort of allocated tag scheme and a callback dispatcher to drive user callback routines associated with each tag. C routines: tag = CPStag( routine, clientdata, typestring ) Allocates a new tag and associates the specified routine with the tag. When the tag is received, the routine is called with the specified (caddr_t) clientdata arg plus the data associated with the tag. The data are decoded and passed vararg-style according to the typestring. CPSreltag( tag ) The tag is released. The previous tag-to-routine binding is released. Any unbound tags are ignored. The tag allocator maintains a roughly LRU allocation of tags to avoid unnecessary confusion. CPStagdispatcher(fdlist); /* or maybe PSFILE(*)[] instead of fdlist? */ invokes a select/dispatch loop. CPSdispatchtag(fd) /* or maybe PSFILE(*) instead of fd? */ is the the dispatcher itself, in case you need to do your own "select" to interface to other things. Given this, you could instantiate a general file access mechanism as follows: tag = newfileaccess( filename ); PostScript code would use this dynamically created tag for sending requests to the "file server." The CID mechanism would be used to discriminate replies. A few extentions to CPS might automate building the PostScript and C stub routines. Further thoughts? Stan Switzer sjs@ctt.bellcore.com