OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming
mechanisms, so many possible ways of doing things, that it is often difficult for the
programmer to decide among them. The guidelines provided by the AES/DC are limited
to only one (albeit an important one) policy issue: portability. The DCE programmer is
still left with many decisions about issues that do not arise in the typical local
programming environment: how to use the name services, which security services to
employ, how many threads to use, and so on.
The Style Guide attempts to answer many of these questions or at least to provide the
grounds upon which an application programmer can base decisions. Of course, the
coverage in these relatively few pages in not exhaustive. The number of implementation
issues raised by the available DCE application programming mechanisms is potentially
unlimited. The Style Guide attempts to cover the major issues that are likely to confront
most programmers at some stage in DCE application design and development.
Aside from attempting to anticipate your questions, the Style Guide may also raise issues
that you may not even have considered. DCE covers a great deal of ground that is
probably unfamiliar to most application developers, such as multithreading and
distributed security. When moving in such unfamiliar territory, it is easy to overlook
potential problems. The Style Guide attempts to alert you to major stumbling blocks in
each area.
1.8.1 Mechanism, Policy, and Style
The Style Guide is based on what is, to some degree, a fiction: that application
development issues can be nicely divided between mechanism on one hand and policy
and style on the other. In theory, the mechanisms of DCE programming refer to the
syntax and semantics required by APIs, IDL constructs, services, and the like. These are
the things about which the programmer has no choice: they must either be done
according to the documentation or not done at all. Policy and style, on the other hand, are
supposed to refer to the things about which the programmer can make a choice:
specifically, which mechanisms to use in given circumstances.
In practice, the distinction between mechanism and policy/style is often vague. The
other parts of the DCE application development documentation set contain much that
could be considered policy and style guidance. And, for reasons discussed in some detail
in the next section, the Style Guide often contains descriptions of the mechanisms of
DCE programming.
Nevertheless, the Style Guide does attempt to keep to the ground of policy and style
issues. It assumes that you already know what mechanisms are available and attempts to
provide guidance about the choices you have in using those mechanisms. One result is
that the Style Guide is not a tutorial; it often assumes knowlege of terms and concepts
that are explained elsewhere in the programmer’s documentation.
On the other hand, the Style Guide does in many cases provide high-level discussions of
the organization and principals of DCE services, such as the security services. The
assumption is that you may already know many of the details but may lack an overall
framework. Often, such a general model is just what you need to be able to make
rational policy decisions.
124246 Tandem Computers Incorporated 1− 35