
Since I don't think Tom always gets time to read this group, I'll take the
liberty of responding to some of this.  If you really want Tom to reply
you should send mail to support@qdeck.com.

A 64k line is certainly going to restrict you far more than the 10mbps
ethernet that we typically run.  How restrictive it will be depends on 
what you run and how you run it.  I would think that a couple of instances
of some really nasty program like "Smoking Clover" would make the link 
useless for anyone else.  On the other hand, probably 50 xclocks quietly
updating every 10 seconds or so wouldn't impact it too much.  In the real
world, you will be somewhere in between these two extremes.

Going by the way I personally use X on a daily basis, I wouldn't want to have
to share that 64k link with more than 3-4 other people.


Our corporate WAN is as unique as any other.  The usage patterns are not very
good predictors of how yours will behave.  The only one of our low bandwidth
links that normally get used in this way is a 56k link to Ireland that they
often use to run a DOS text based client end of a client-server database 
remotely from the DVX machine behind me. Since the server end is (or was) always
at this end (California) it is faster to remotely run the client via DESQview
X and have a short hop to the server than running the client locally and having
a long hop to the server.  As I warned you, this tells us very little about
how you usage pattern will fill a 64k ISDN link.

Running Word for Windows remotely is going to itself be very usage dependent.
Let's break it into pieces and look at it.  Tracking the mouse pointer is easy
and efficient to translate from Windows calls into X. Popping up a menu is a
little more involved and will generate some traffic.  Restoring the screen
that was covered by that menu may be easy and may not be.  Does the server
that it's displaying on have backing store?  If so and the server had enough
memory the display can be updated locally and will generate little network
traffic. If no backing store, then what was being covered up?  If it was a 
solid colored rectangle of space we can tell your xserver to draw that quite
easily.  If it was a full color backdrop of Ren & Stimpy we may have to send
it back to the X server bit by bit.  DVX will do its level best to only redraw
that small area, but in some unusual cases the entire screen may need to be 
repainted.  Assuning a 1024x768 screen with 4 bits per pixel that's 3145728 bits
that has to be sent.  Worst possible case you're looking at about 50 seconds.
In reality it would never be this bad since the screen will always have parts 
that will be tranlatable into higher level X calls.


X was designed from the ground up to be efficient across a network.  It's 
pretty good for this.  X programs are best, DOS text programs are almost
as good (since we conert them to X easily).  Something like WinX is a hybrid.
We intercept the calls Windows makes to it's graphics driver/ mouse driver
keyboard driver and convert them to X.  The calls Windows is making are in
no way designed to be efficient on a packet switched network.  We go to a 
lot of trouble to convert them to the highes level Xlib calls we can, but
we are somewhat limited because we only know what Windows and its applications
tell us.