Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: X, X-server and X-library
Message-ID: <4430@jade.BERKELEY.EDU>
Date: Tue, 21-Jul-87 17:28:42 EDT
Article-I.D.: jade.4430
Posted: Tue Jul 21 17:28:42 1987
Date-Received: Fri, 24-Jul-87 02:40:27 EDT
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 39

People have been pushing the idea of splitting programs into two
parts, one that swallows configuration commands or whatnot, and a
second that sits in the background and plays server. The server
might/might not open or WindowToFront() a window when it gets nudged.

This is all good stuff. I went through it with mg a couple of months
ago (an Emacs that appears to start in < .5 seconds is a killer demo as
far as I'm concerned :-). However, I carried it one step farther.

Like Perry with FACC, I wanted mg to free up memory if the sytem
needed it. Unlike FACC, I didn't have any problems with mg exiting if
it wasn't being used. The only mechanism that seemd to want to work
was a library. So I designed (but never built) the following "edit"
library:

	Open - does the usual things, and will start an editor if there
		isn't one running.
	Edit - pass the edit server a file name. Wait for the editor
		to indicate that the user is through with it, and
		then return.
	 - hooks to allow Edit on multiple files.
	Close - just decrement the use count.
	Expunge - exit.

Obviously, the Edit and  entries can be whatever your application
needs. The other three are required for libraries. By doing this, you
get the benifit of the user-command/server split, plus a program that
will exit if you need the memory and wouldn't otherwise have it
running.

I never got around to implementing the library part. I'd sure like to
see it done, though.