Shared NeWS/Display Postscript

NeWS is based on a very different paradigm than X. Rather than a specific protocol, NeWS is based on extensions to the Postscript page layout language to handle displays and events. How to extend this to provide shared windows would be very different from the natural extensions to X. Shared-X does this by keeping an external copy of the state information and resources that are normally inaccessible inside the X server. The PostScript language that NeWS uses allows the client application to build up new function definitions inside the NeWS server. The client can then call these new functions as required. To provide a Shared NeWS server we must duplicate these function definitions in any new NeWS servers joining a conference. This is relatively easy to do, and purely for the duplication of function definitions, a centralised architecture may suffice. This will then allow the same postscript function calls to be multicast to the NeWS servers. However NeWS servers still contain state information that is not directly generated by the client such as colour map allocations. In order to allow multicast some mapping will be still required at each server. However as NeWS servers are, by definition, extensible by the client, it should be possible for a bridge to download the mapping code directly into the NeWS server itself. In any case a bridge will still be required to arbitrate return values from the servers in order to present a consistent image to the client.