The second choice involves how to get a binding handle. Again, this is a choice that is at least partially dependent on decisions already made. The client can always generate a binding handle for itself; the problem is where to get the information that belongs in it. There are two general solutions, as follows:
· The client imports from the namespace binding handles that already contain the necessary information, or
· The client receives the information in string form from user input, from a file, from another server, or from any other source. It then converts the string into a binding by calling rpc_binding_from_string_binding( ).
The normal way for a server to make its location known to clients is to export its binding information into the namespace. The client can then call the following RPC name service library routines to import one or more bindings from the specified namespace entry:
rpc_ns_binding_import_begin(entry_name_syntax, entry_name, if_handle, \
obj_uuid, &import_context, &status);
rpc_ns_binding_import_next(import_context, &binding_handle, &status);
rpc_ns_binding_import_done(import_context, &status);
The name service sees to it that only compatible bindings exported under the specified interface, with the optionally specified object UUID, will be returned to the client. (Note that the interface specification is not contained in the binding, although it is exported to the namespace entry where it is used by the name service for matching entries to prospective importers.) The object UUID specified by obj_uuid is contained in the binding, if it is present. This is the object UUID that was (optionally) registered under a type UUID in an earlier step. Even if obj_uuid is not specified in the import call, it will be returned in the binding handle(s) if it was exported by the server.