Retired Document
Important: Support for DirectoryService plug-ins has been deprecated and will be removed in a future release.
A new architecture was introduced in OS X v10.9 to allow the creation of native Open Directory modules. Unlike DirectoryService, opendirectoryd
uses modules implemented as a standalone process that uses XPC to communicate with opendirectoryd
. Implementing a module as an XPC service ensures a private address space and improves security and reliability, because modules cannot crash another module or opendirectoryd
.
Processing Open Directory Requests
Open Directory passes to the appropriate Open Directory plug-in certain requests from Open Directory clients. The requests correspond to a subset of the Open Directory function calls described in Open Directory Programming Guide. Every Open Directory plug-in must be prepared to process each of the requests described in this section even if only to respond that the requested service is not implemented (eNotYetImplemented
) or not handled (eNotHandledByThisNode
). To indicate the outcome of processing a request, the plug-in should return a result code from the list of result codes documented in Open Directory Programming Guide.
The plug-in must be prepared to process requests for each of the Open Directory functions described in this section.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As an alternative to processing dsCloseAttributeList
, dsCloseAttributeValueList
,
dsGetRecordEntry
, dsGetAttributeEntry
, and dsGetAttributeValue
requests in the plug-in, applications can use client-side buffer parsing to process these requests. For information, see the chapter Client Side Buffer Parsing.
See Runtime Environment for information on three special cases in which the ProcessRequest
entry point of an inactive plug-in is called.
Copyright © 2015 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2015-03-09