Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!lll-crg.llnl.gov!casey
From: casey@lll-crg.llnl.gov (Casey Leedom)
Newsgroups: comp.windows.x
Subject: DRAFT: Point-to-point X protocol proposal (long)
Keywords: DRAFT, protocol specification, proxy server, server engine
Message-ID: <26360@lll-winken.LLNL.GOV>
Date: 3 Jun 89 19:38:43 GMT
References: <26333@lll-winken.LLNL.GOV>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@lll-crg.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 29

| From: Peter Scott <PJS@grouch.JPL.NASA.GOV>
| 
| I have a suggestion, that it be implemented using a command cache.  Since
| the problem is bandwidth (1200bd compared to ~T1), have the X server
| group sets of protocol requests that look as though they might be
| repeated (e.g., primitives that make up the frame for a text window), and
| with each set, send over to the engine a message that it is naming that
| set of commands macro n.  The engine puts that set of commands on the top
| of a stack, and whenever the server would send that same group of
| commands, it sends instead the somewhat shorter command, "do macro n".
| This causes the engine to execute the commands it has stored, and put
| them back on top of the stack.  When it runs out of space it takes the
| bottom macro off the stack, and sends a message to the server saying,
| "macro n forgotten".  If you can make the server intelligent enough to
| recognize reasonable command groupings then this can save oodles of time.

  This sounds like an excellent suggestion, but I don't know enough about
the X protocol and traditional server design to know whether the problem
of recognizing ``groups of protocol requests that look like they're going
to be repeated'' is a doable task.

  Certainly such a design feature in the X Engine Protocol would address
the endlessly debated RISC/CISC question quite nicely.  We could only
provide those graphics primitives in the X Engine Protocol that were
known to be used frequently.  These would probably form a fairly small,
simple RISC-like set.  Then your macro idea would effectively give us a
dynamic micro-code extension capability.

Casey