3.1.2 Synchronous requests
Most of the operations have the option of operating asynchronously according to the model described above. A few operations must always operate synchronously. These are generally related to the "life cycle" of TSPI interactions, such as initialization or shutdown. Such operations do not return until they are complete. The designer of a Service Provider should make a strong attempt to keep the execution time of these operations short. For example, there is an "Open" operation called at initialization time that prepares the Service Provider and TAPI DLL for subsequent operations on a device. A Service Provider whose implementation is split between the client PC and a dedicated server may have reasonable confidence that it can communicate with its remote server. Its implementation of "Open" might just allocate and initialize data structures to represent the device and return, postponing end-to-end communication until some real operation is requested.
Any such "optimistic" implementation of a synchronous operation can of course later encounter resource limitations or remote communication failures. In general these cannot be entirely prevented even by a "conservative" approach; Service Provider designers will have to choose the best tradeoff between reliability and performance. A failure of this kind should be handled gracefully wherever possible. From the point of view of TSPI devices should remain valid for bookkeeping purposes even if they return failure status for any operation requested.
Implementing an optimistic approach for synchronous requests should not be done at the expense of correct semantics for the operation. Returning to the "Open" example, if opening a device needs to compete for and reserve some scarce, non-sharable resources such as communication ports, etc., it should probably do so even if it is somewhat time-consuming.