Today Panasonic contributed an implementation of the OpenDOF protocols in C. This implementation is fully compatible with the previously released Java libraries, and allows interconnected systems that use any mixture of the two libraries. Panasonic will continue to contribute code over the next months.
Our first week had some amazing news coverage!
The Permission Type Registry
Permission Types are grouped into the Permission Type Registry with each Permission Type allowing for extendable methods of identifying permissions.
When an operation is initiated, binding permissions at each DOF component determines whether the operation is allowed to be transmitted through that component. Binding permissions are permission type 1 in the Permission Type Registry. A binding permission consists of four parts that determine what the permission allows:
actions
object identifiers
interface identifiers
attributes
Topology refers to creating the DOF node and its components of connectivity: systems, connections, and servers. It also covers proxies and connection listeners. Finally, it covers setting up multicast environments, hub and point connections, and responding to Connect-level interest. Although it is not a requirement, completing the Operations Training is recommended before tackling your own topology design.
SocialCompare
Some useful API tips
The API uses a number of common conventions in naming:
Anything called a “listener” is an interface that can be implemented to listen for specific types of operations and perform callback functionality. Requestor listener interfaces are usually called “operation listener,” so if the name of the interface doesn’t include the word “operation,” it usually is provider functionality.
An Object Access Library (OAL) written in a specific programming language that is used to access data which meets the standards of DOF technology.