Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!lll-winken!sun-barr!newstop!sun!kimba!hvr
From: hvr@kimba.Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: Driving a User Interface From a File
Message-ID: <131930@sun.Eng.Sun.COM>
Date: 16 Feb 90 02:54:21 GMT
References: <7064@jpl-devvax.JPL.NASA.GOV>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 72

In article <7064@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes:
>
>My guess is this could be done with a hacked XtMainLoop.  Starting
>and stopping the collection of events from the user, as well as the
>parameterization bells-and-whistles, would be handled therein.
>
>Ideas, anyone???

Journaling or scripting is a very common request from end-users, and a
very difficult thing for a server or toolkit to supply--correctly.

One could do this in XView by using notify_interpose_event_func() and
notify_send_event(), but the problem of synchronization and reproducing
certain conditions remains.  It could be done for a special case, but
it is harder to make it a general piece of functionality.

OpenWindows provides a journaling tool which takes advantage of the NeWS
side of the server, but this too is not bulletproof.  Any kind of tool
like this is subject to race conditions in the operating system, network, 
server, toolkit, application or in the case of X11 the protocol.

Classic example, you have a tool in position X, Y which pops up a menu,
the user selects an item in the menu which does a task.  When you replay
the same sequence, the tool is now in a different location, the menu hit
may or may not occur within the scope of the application, or the time
between events is different, so order becomes more difficult, etc...

It's much easier to model the calling sequence of action procedures than
to duplicate the user's interaction.

Anyway, I do not doubt that a single application could do this, but it
is a much more difficult problem to provide journaling for the general
case...when you have interaction between two processes.

To abstract a bit, consider the scripting language for /bin/sh.  Most
shell scripts will execute one task to completion before starting the
next one.  If I were to start two builds in the same directory by putting
them into the background:

% make &
% make &

The second "make" has the potential to clobber all the work of the first
"make".  To avoid this, they are processed sequentially.  The same principle
holds for programs which rely on output from another for their input:

% who | sort

The "sort" process will not execute until it has received its input from
the "who" process.

If we changed this a bit to put both who and sort into asynchronous mode
with some kind of checkpoint in a file:

% who > /tmp/who.out &
% sort < /tmp/who.out &

We have just introduced another race condition.  Will "who" finish in time
for the "sort" process?

So, in the scripting language for /bin/sh we assume certain conditions:
	well defined scripting language 
	same behavior interactively as non-interactively
	scripting language interpretor
	tasks are synchronous when timing matters
	tasks are asynchronous when timing does not matter (backgrounding)
	well defined path for input and output streams (checkpoint with pipes)

Anyway, this makes a very small stab at some of the more obvious issues
involved with journaling.

Heather