Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: how do I tell the size of a pseudoterm window?
Keywords: layers xt
Message-ID: <9136@smoke.BRL.MIL>
Date: 11 Dec 88 04:59:51 GMT
References: <2081@vedge.UUCP> <6766@spool.cs.wisc.edu> <564@auspex.UUCP> <665@auspex.UUCP> <1107@sdcc7.ucsd.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 57

In article <1107@sdcc7.ucsd.EDU> muller@sdcc7.ucsd.EDU (Keith Muller) writes:
>As far as I know there are only three ways to create a layer:
>	1) with the mouse
>	2) with a host resident "agent" subroutine call
>	3) from a terminal resident  program

Correct.

Keith is pretty well informed about this stuff, so much of what I have
to say is for the benefit of those who don't know much about layers.

>None of these directly support the X client model where a client is on a
>remote host and can directly communicate to a X server (e.g. there is not
>a network version of the openchan() agent library function). It would not be
>too difficult to add a "netopenchan()" agent library function (at least to
>the 4.3BSD 630MTG software it can be done). I assume that this would be an
>attractive feature?

The X client model and layers aren't entirely conformable.  (That's
what started this discussion!)  Personally I think the hostagent
feature should work from any host that is being used in the window.

For a specific example, consider remote-host use of "sam":

	human user of DMD/MTG terminal
		|		^
 mouse/keyboard	| movements,	|
		| clicks,	|
		| dragging,	|
		| keystrokes	| bit-map display
		v		|
	samterm running in DMD/MTG layer with layersys RTOS support
		^
  terminal port	| special "sam" transaction record protocol
		v
	original "sam -r remote_host_name" process on layer host system,
	now acting just as a "wire".
		^
 net connection	| transparent rexec I/O streams
		v
	remote_host "sam -R" process (file editing server)

Now, "sam -R" doesn't manipulate windows using the hostagent feature,
but suppose it did.  The associated ioctls really should be sent to the
layer host system (this is one of the things streams are good for).
The layer host can take care of the layer manipulation, because it
knows how.  The remote system need know nothing about layers or xt.

You probably have quite a problem getting the Berkeley/Sun network stuff
to support this scheme.  It should be easy with current UNIX System V.

A workaround for use with existing puny network facilities is to have
the "sam -R" process communicate its needs to samterm and have samterm
communicate with the layer host to keep it apprised of its window
manipulations.  In fact that's pretty much how existing DMD/MTG software
does operate.  (The layer host is informed via the control channel on
the terminal port, by layersys.)