Our approach in MOVIE is to design an integrated MovieScript-based
model for graphics, GUIs and visualization. We adopt the original
PostScript model for scalable two-dimensional graphics as defined in
[Adobe:87a] and we extend it by including other graphics
subsystems. Even in the PostScript domain, however, we face
uncertainties due to competing models offered by the DPS server from
Adobe Systems, Inc. and the NeWS server from Sun. Since none of these
Postscript extension models is complete (e.g., none offers the model
for three-dimensional graphics), we don't follow any of them in
building the MovieScript extension. Only the intersection of both
models, given by the original PostScript model for printers, is adopted
``as is'' in MOVIE, and we build custom extensions towards windowing
and event handling, compatible with other Open Systems components. The
conflicting extension models of DPS and NeWS are not part of the
MovieScript design but these language sectors can be accessed from the
MovieScript code since the MOVIE
DPS/NeWS interface model
supports programmability of remote PostScript servers.
Remote PostScript devices such as NeWS or DPS servers are accessed from the MovieScript code by the operators gop and gdef. The syntax of gop is the following:
where key is the literal name, 
and 
are
numbers, code is a MovieScript object capable of defining some
remote PostScript code, and rop is the MovieScript operator
(with the prefix ``r'' standing for ``remote''). Here, gop
installs the user-defined graphics operator (implemented as a
PostScript procedure) in the remote PostScript server and it also
creates the local MovieScript operator rop associated with this
remote operator. Both local and remote operators are associated with
the common name, specified by key. The code object can be a
MovieScript procedure or string. The execution of rop consists
of sending 
arguments from the MOVIE operand stack to the
NeWS/DPS operand stack, executing remote procedure in NeWS/DPS,
associated with key and previously installed in NeWS/DPS by
gop, finally transporting back 
output objects from
NeWS/DPS to MOVIE.
The associated gdef operator is simply a sequence: { gop def }, that is, it installs rop in the local dictionary under the name key. In other words, the action of gdef is fully symmetric on local (MOVIE) and remote (NeWS/DPS) servers. The gop output format can be used to handle rop differently-for example, by installing it as an instance method within the MovieScript class model.
MovieScript support is also provided to control the connection status and buffering modes along the PostScript-based communication lines.
The interface model described above was developed first for the NeWS server [Furmanski:92d], and it is now ported to DPS [Podgorny:92b].