
 DIPC was designed to enable people to
 1) build multi-computers without using any special hardware and
 2) program the resulting system very easily

 The problem here was to bring new functionalities to a pre-existing
operating system. The design choices could not be made as freely as when
designing from scratch. It did not seem appropriate to introduce completely
new features, or to change existing mechanisms in a drastic way. 

 DIPC design goals:

 1.0) Simplicity of the system.
 Preferring simplicity of the algorithms whenever a conflict between that and 
the performance arises (this may change in future versions). 

 2.0) Transparency of the distributed facilities.
 Doing distributed actions should not be very different from doing the same 
actions in a single computer.

 3.0) Independence of network characteristics.
 The programmer should not be concerned with physical characteristics of the 
computer network, such as network topology, addresses, etc.

 4.0) Compatibility with legacy software.
 Non-distributed programs using System V IPC mechanisms should be able to 
coexist with distributed programs.

 5.0) Simplicity of programing.
 Preserving the UNIX semantics would help those programmers who are already
familiar with UNIX, and prevents the need to master some completely new
programming models. Others would benefit from the wealth of information
available for System V IPC.

 6.0) Independence of any specific programming tool or model. 
 Programmers should be able to use DIPC in any language that can access
operating system's functions. (S)He is not limited to any specific language
or software engineering methodology.

 7.0) Ability to turn legacy programs into distributed ones. 
 It should be relatively easy to port older programs, using System V IPC 
mechanisms and probably running on multi-processors, to the new system,
making them distributed programs.

 8.0) Ability of the programmer to influence program performance. 
 The main performance parameters (frequency and amount of data exchange between 
machines) are in the hands of the programmer.

 9.0) Ability to develop programs on inexpensive hardware.
 Programs could be developed on a single computer and later used in a 
computer cluster.

 10.0) Running DIPC code in user space as much as possible.
 This is the trend followed by Microkernels (I am a former Amiga user who 
believes in Microkernels). Of course there are some inevitable needs for 
kernel information and services. 

 11.0) Trying to make DIPC work on WANs (Wide Area Networks).

 12.0) Considering the need to use DIPC in a heterogeneous environment.


