next up previous
Next: 5. On Data Processing Up: 4. WEBeye: A Case Study Previous: 4.2 Software Structure

4.3 Summary

Complexity is the enemy of flexibility, robustness, and maintainability. Modularity is the best defense, and the free use of fullweight processes as modules has been illustrated in this chapter. These processes do not share memory, and only communicate by passing messages through pipes and over the network. This design restriction is not found to be burdensome in practice, and fits in well with SETL's value-semantics orientation.

The ease with which arbitrary numbers of clients can be tracked in a SETL program works hand in hand with this attention to modular design. This keeps all the programs in the WEBeye case study small and readable, supporting the Box's flexibility, robustness, and maintainability. Efficiency has been assured by isolating the CPU-intensive work in the image-pump program which is written in C and takes advantage of an existing JPEG conversion library. With this division of labor, we find it unnecessary to schedule programs for destruction by labelling them prototypes: the SETL programs already consume almost no resources compared with image-pump.

However, the interfaces between modules are not checked by an external party. There is currently nothing like CORBA's Interface Description Language (IDL) [153] for specifying what should and should not be in the maps that pass between SETL programs, and certainly nothing approaching the power of Ada specifications to pin down interfaces. The wise SETL programmer will therefore insert a few redundant checks on any received map. This is actually a very minor bit of housekeeping compared to the checking that needs to be done on data arriving from external sources on a network in a language-independent setting. In any case, good form in a piece of data is not usually enough to ensure that it makes sense when and where it occurs. The most subtle and extensive checks will be semantic and context-dependent.

Similarly, an exception-handling mechanism can be helpful, but does not relieve the programmer from considering exceptional cases. To the extent that processes which might reasonably be expected to raise exceptions are kept small and well isolated, the ``safety net'' effect for which most exception handling is specified is already achieved in the modular SETL designs presented here.

In the next chapter, we look at some more things the programmer can do to design robust, flexible, maintainable interfaces and programs for data processing over the Internet.


next up previous
Next: 5. On Data Processing Up: 4. WEBeye: A Case Study Previous: 4.2 Software Structure
David Bacon
1999-12-10