Date: Wed, 9 Aug 89 9:28 BST
From: Tim Glauert <cam-orl!thg@uunet.uu.net>
To: xvideo@expo.lcs.mit.edu
Subject: Portable VEX servers.
Message-Id: <89/08/09 09:28.150 thg@mango>

How portable is VEX server code going to be?

The server side of VEX will clearly be in at least two parts, DIVEX and DDVEX.
It is extremely desirable that the amount of work to port either part to a new
server is as small as possible because this will spread VEX quickly. The
problem is that the interfaces must be clean enough so that one part can be
changed without work being done on the other. It should be possible to
add DDVEX code without changing the server code or the DIVEX code.

Some examples for consideration are:

* The implementation of a Region in the server: DDVEX is likely to need to
access the clipping region for a window, but this is held in a server-specific
format. So perhaps DIVEX should provide utilities to unpick a Region?

* Routines in the Screen structure: DIVEX must cleanly trap any calls to these
routines which might be needed by DDVEX. (e.g. DDVEX might want to be told
when the screen is being blanked by the server)

* Command-line arguments: DIVEX should let DDVEX inspect the command-line
arguments to the server. There is no way for a standard extension to do this
so DIVEX must contain non-standard code for each particular workstation.

* Handling of Expose/Cover for video windows: DIVEX should be able to inform
DDVEX when part of a video window is covered or uncovered. This requires
non-standard extensions to a server.

So DIVEX code should be ported once for each workstation, preferably by the
server implementors, and then any implementation of DDVEX can be added to
this. This avoids having a different DDVEX implementation for every server.
However, the definition of the protocol will have a larger effect on how easy
this is.

EXAMPLE:

As an example, consider the following real-world problem which I am facing:

Our video hardware generates 8-bit grey-scale and may be attached to any
low-resolution display. The host we are currently using has a 4-bit colour X
server provided by the manufacturer. Getting linkable binaries out of the
manufacturer will be a real struggle, getting the source is out of the
question.  Given the current protocol I need an 8-bit Pixmap to digitise the
video, so what do I do? Implement a complete X server for the machine myself?
Only digitise to 4-bits? Add a non-portable hack to deal with this problem?

The requirement for an 8-bit Pixmap is a `feature` of VEX whose consequences
haven't been thought out. Why do I need to be able to handle Pixmaps deeper
than I can actually display? The ability to suck directly from a VIDEOIN into
a client Image structure would solve this problem simply and cleanly. So would
the ability to create video buffers of depths which don't support Pixmaps.

THE BOTTOM LINE:

Serious thought needs to be put in on all the interfaces between the server,
DIVEX and DDVEX. Consideration needs to be given to the effect of various
features of VEX on this requirement.

	Tim.

Tim Glauert, Olivetti Research Limited,		|	thg@cam-orl.UUCP
24a Trumpington Street, Cambridge, England.	|