[89] in Zephyr Mailing List
Something interesting from the Zephyr archives!
daemon@ATHENA.MIT.EDU (Tony DellaFera)
Fri May 21 08:36:49 1993
To: zephyr@Athena.MIT.EDU
Cc: tony@tay1.dec.com
Date: Fri, 21 May 93 08:32:59 -0400
From: "Tony DellaFera" <tony@tay1.dec.com>
Hi all,
Rich has dug up something you all might be interested in seeing.
The names in the discuss meeting are:
geer: Dan Geer
Saltzer: Jerry Saltzer
dgg: Dave Grubbs
jg: Jim Gettys
mike: Mike Gretzinger
tony: Tony DellaFera
jtkohl: John Kohl
Love this kind of archana. I have TONS of it from the early X Window
System days, including the message where Jim Gettys, Bob Scheifler and I
are musing about "what to call this window system" :-)
Tony...
------- Forwarded Message
Return-Path: rptaurie@Athena.MIT.EDU
From: rptaurie@Athena.MIT.EDU
Received: by m11-116-3 (5.57/4.7) id AA22974; Fri, 21 May 93 03:25:48 -0400
Date: Fri, 21 May 93 03:25:48 -0400
Message-Id: <9305210725.AA22974@m11-116-3>
To: tony@tay1.dec.com
Subject: Early Zephyr document
Hi,
I found this "document" on Zephyr (before it was named Zephyr) in a discuss
meeting (a sort of bulletin board) where random bits of interesting, old
info is archived. I'm not involved with Zephyr development or know
anything more about its history, so I'm afraid I really can't help you out,
otherwise.
Good luck,
Rich
- ---------- Begin forwarded message ---------
[0051] jtkohl@ATHENA.MIT.EDU Lore 01/08/86 11:39 (56 lines)
Subject: embryonic XWindowGram stuff
From: <geer@ATHENA.MIT.EDU>
Date: Wed, 8 Jan 86 11:39:32 EST
To: Saltzer, dgg, geer, jg, mike, tony
Subject: XWindowGram protoprotocol
This is to represent a first cut at a XWindowGram design, as discussed
yesterday. I assume sitting ducks do not need to invite gunfire...
0. <wall>, <talk>, <write>, and (and an expanded sense of) <biff> are
the services thought to be the most immediate consumers, and to
represent the minimal service level we currently need. actually,
scratch <write> based on /etc/comsat, or so it was said.
1. the presence of both a nameserver and an authentication server are
presumed.
2. the nameserver will (need to be able to) provide ?both the login
host and the window manager host for user in question.
3. a notification server will be created, leading to the overall
functional schematic below:
--------- ---------
discovered event| |
(application) _| |_
| | notify -> | | notification
| |:::::::::::::::| | server
|_| <- ack/nak | |
| <<<| |
| v |=| <- slot for rule base
--------- open v |_|
display v |
msg v |___
>>>| |
| X |
|___|
|
---------
4. filtering by class & source, tailorable by the user via the ``slot
for rule base'' in the above, will be supported. the definition of
``class'' is that that the authentication server can authenticate,
viz. people and services. ``source'' means filtering on net addresses.
5. the semantics of ack/nak need definition, but note that a demand
for highest quality ack may imply that the server becomes a client of
the notification server of the original client so that, say, assurance
can be had that a message has not only been received by the client,
forwarded to X, put up as a window, and but also moused.
6. in short, the needed list is:
server/client daemons
ack semantics
rule system
- --dan
- --[0051]--
------- End of Forwarded Message
