Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <2000038@ccvaxa>
Date: Tue, 15-Apr-86 16:28:00 EST
Article-I.D.: ccvaxa.2000038
Posted: Tue Apr 15 16:28:00 1986
Date-Received: Thu, 17-Apr-86 04:20:53 EST
References: <3289@sun>
Lines: 19
Nf-ID: #R:sun:-328900:ccvaxa:2000038:000:1074
Nf-From: ccvaxa.UUCP!aglew    Apr 15 15:28:00 1986


[Comment:] I find the term `shell layers' inappropriate. It seems to imply, to 
me, subshells, perhaps not even tree structured. When I think of multiplexing
on a wire I do not think of layered sets of data, with this layer being above
or below that - I think of a switch.
   The term `layers' is really only appropriate to an aspect of the
implementation, in terms of (overlapping) windows.
   [Has anyone ever made a non-layered windowing system - one where you
can get cycles of overlaps? Wouldn't work with rectilinear windows.]

[Question:] does the `shell layering' system include true virtual terminals 
mapped into a memory image of the screen display? If so, nice, but could
quickly start consuming large amounts of memory (say I want to have N 
1Kx1K colour maps, but I'm only displaying the equivalent of 1.5 at any time).
Is there provision for less storage costly alternatives - a window resized
or revisibled interrupt?

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms