Programmers writing internationalized RPC applications can develop their own character and code sets compatibility evaluation routines if their applications' needs are not met by the DCE RPC evaluation routines. These programmers may want to use the following DCE RPC routines within their evaluation routine:
· The rpc_rgy_get_codesets( ) routine
· The rpc_cs_char_set_compat_check( ) routine
· The rpc_cs_binding_set_tags( ) routine
· The dce_cs_loc_to_rgy( ) routine
· The rpc_ns_mgmt_read_codesets( ) routine
· The rpc_ns_mgmt_free_codesets( ) routine
Refer to the OSF DCE Application Development Referencefor complete details about these routines.
Programmers who write their own evaluation routines can also select when evaluation is performed; that is, they can defer evaluation from occurring in the client code, or they can defer evaluation completely at the client side and let it take place in the server instead. Programmers who desire to defer evaluation to the client stub can write an evaluation routine that sets the client's and server's supported code sets into the binding handle returned by the client, then write the evaluation logic into the stub support routine for tag-setting so that it performs evaluation within the client stub.
Applications that do evaluation in the client stub take the chance that the binding handle that is evaluated is the only binding handle available. For example, suppose there are three binding handles. Two are character and code set compatible, and one is incompatible. The incompatible binding is selected for RPC. If you evaluate in the tag-setting routine, you cannot reselect to get the other compatible bindings.
In general, it is recommended that character and code sets evaluation take place in the client, rather than the server, for performance reasons. Also, once the server is selected and a connection is established between it and the client, the client cannot typically reselect the server because the code sets are incompatible.
Within the client, it is recommended that evaluation be performed in the client code rather than in client stub, because deferring evaluation to occur in the client stub removes any way for the client to gain access to other potential binding handles.