From: dcc@ATHENA.MIT.EDU
Message-Id: <9010261954.AA02306@BOOM>
To: vex@expo.lcs.mit.edu
Subject: An alternative approach to handling device control and connectivity.
Date: Fri, 26 Oct 90 15:54:25 EDT


In the debate about including device control and connectivity in VEX,
I've been trying to converge on what the central technical point of
contention is.

While it is claimed that supporting device control and connectivity is
optional in VEX, what remains is clearly deficient when considering
the needs of alternative video device and network servers.  

When pressed on how VEX achieves frame accuracy for instance, Todd
points to the device control mechanism and claims it can be used for
this purpose.  How this is done remains unspecified (though I agree
such a control could be designed), but more importantly unspecified
interaction between device control and display rendering must occur.
Those interactions are implicit in VEX and not standardized such that
other approaches can take advantage of them.

Stated another way, the justification for adding device control to the
X protocol is that realtime interaction between device control and
display rendering is required for some systems, and that co-locating
the two activities within a single process (the X server) is therefore
necessary.  While I agree that such realtime interactions may be
needed and that co-locating the two activities within a single process
is a legitimate approach, it does NOT follow that device control and
display rendering should be part of the same protocol.

The same arguments apply to device connectivity and video networking.

My approach is to define the video extension such that multiple device
and network servers could interface to it.  If realtime interactions
are needed between multiple servers, co-locating the servers in the
same process context is a legitimate approach.  Such a process would
support multiple independent protocols.

/David