V.2 Job Control

[Guy Harris]

> (An aside, was I halucinating or were people REALLY booing
> the presenter?)

No, you were not hallucinating.

> Anyway, my questions:

> 	3) You can't signal a process to tell it to 'repaint'
> 	   the screen with the V.2 JC stuff. Is there anyway to get
> 	   around that? 

No.  That is one reason people were booing the presenter.

> 	4) The presenter (cant remember who) made the comment that
> 	   the Berkeley JC had severe problems with its definition.
> 	   I've never loved the implementation but isn't the problem
> 	   in the implementation rather than the definition?

I don't remember what the comment was, but it is interesting to note that most
UNIX programs (all those which don't put the terminal or the tty channel in
a non-standard mode or move the cursor other than by outputting lines) don't
have to change *at all* to work with job control.  Those that print a prompt
*can* be changed (it improves their esthetics), but *need* not be.  Screen
editors probably don't *have* to be changed, either, but they're a *lot* nicer
if they do - if they don't, they give the same inadequate behavior as the
S5R2 "job control" does.

> 	5) The comment was made (by the presenter) that his JC stuff
> 	   is a poor mans BLIT. Why then is it called job control when
> 	   it is more a primitive window manager (complete with virtual
> 	   ttys!!)?

It's called "job control" because, to some degree, it's a marketing ploy.
It is truly a primitive window manager; you can't "control jobs" by stopping
them.  It also has no way of notifying the program that it has had control
of the terminal taken away from it, which means that any program which assumes
that it has total control of some terminal, either physical or virtual, won't
work unless the virtual terminal mechanism is modified to track all the
changes to the terminal state made by that program and to always switch the
state of the physical terminal to match the state of the currently active
virtual terminal.  This would mean it would have to keep a *FULL* screen image,
and keep track of all sorts of internal state for the virtual terminal.  This
either means it has to know everything about every model of terminal anyone
would ever hook up to a system running S5R2, or it has to provide a "virtual
terminal" which is a powerful enough model to be sanely emulated on every model
of terminal anyone would ever hook up to a system running S5R2.

In short, to do it "correctly" would mean implementing a gigantic package which
would dwarf "curses" in complexity either inside the kernel or in a process
connected to all terminals using the virtual terminal facility with a
multiplexed-file like facility; I'm not even sure this is implementable given
the variety of terminals out there.  So any claims by Bell that this is the
"correct" way to do it, as opposed to the Berkeley method which is "incorrect",
are bogus.  The Berkeley method distributes knowledge about the peculiarities
of the terminal to the programs using the terminal; the Bell method tries to
centralize this knowledge but fails because the only such knowledge that
it centralizes is the "ioctl"-settable tty port modes.

	Consider the "ged" program - a Graphical EDitor, supplied with S3 and
S5, for the Tektronix 4014 - modified to work on a "VT100-plus-graphics-board"
terminal which has a VT100 mode and a separate TEK4014 emulation mode.  Now try
to imagine this running on a "virtual terminal" using the S5R2 virtual terminal
facility.  Can you say "totally scrambled screen?"  I thought you could!  The
"layer shell" doesn't know doodley about turning the TEK4014 emulation mode on
or off.  You would have to implement commands in "ged" to turn emulation mode
off and clear the screen, and to turn emulation mode back on and redraw the
screen.  Then, you would have to run the first command before switching out of
that layer and run the second command before switching into that layer.  But why
not just have a signal sent to the program which tells it that its layer is
being left or entered?  Then the program could automatically run those commands
which would make the user interface to the layers facility infinitely superior
(less chance for errors, less typing, etc. - "cleaner and simpler but much
more of a pain to use" is usually *not* a win).  Well, that's what SIGSTOP and
SIGCONT are for in the Berkeley job control mechanism.

	It sounds like they adapted an idea that wins on the Blit (because
the Blit is specialized hardware and software *designed* so that a virtual
terminal idea will work) and tried to make it work on arbitrary hardware.
Given how arbitrary terminals can be, I'm not surprised that such an attempt
failed.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy