1*e2415fa7SEd TanousThe following are guidelines for bmcweb's use of DBus to construct Redfish 2*e2415fa7SEd Tanousschemas: 3*e2415fa7SEd Tanous 4*e2415fa7SEd Tanous- Do not require (ie set 500 internal error on) an implementation present a 5*e2415fa7SEd Tanous property that wasn't in the first commit of the interface unless it can be 6*e2415fa7SEd Tanous verified that _all_ OpenBMC implementers of the interface support that 7*e2415fa7SEd Tanous property. 8*e2415fa7SEd Tanous- If an implementation presents a property that doesn't match the type specified 9*e2415fa7SEd Tanous by the interface at any version, it shall be repored as a 500 error. 10*e2415fa7SEd Tanous- If the DBus interface definition has an "unknown" or "unspecified" value, 11*e2415fa7SEd Tanous detecting these will omit the property from the Redfish tree, in line with the 12*e2415fa7SEd Tanous Redfish specification. 13*e2415fa7SEd Tanous- All DBus interfaces on all object paths are optional. An object missing an 14*e2415fa7SEd Tanous interface is never an error, and shall simply omit the relevant properties 15*e2415fa7SEd Tanous and/or actions from that Redfish Resource. 16*e2415fa7SEd Tanous- bmcweb will code to the DBus interface itself. This means that daemons are 17*e2415fa7SEd Tanous expected to handle functionally bad, but DBus-correct input in their own 18*e2415fa7SEd Tanous process, and return appropriate return codes. This is done to reduce the 19*e2415fa7SEd Tanous duplication in input processing between the various user-facing daemons. 20*e2415fa7SEd Tanous- There are interfaces for which there is an expectation that there will only 21*e2415fa7SEd Tanous ever be one producer in the project (ex bmc networking, user management). In 22*e2415fa7SEd Tanous these cases, it is desirable to call the daemon by well known name directly. 23*e2415fa7SEd Tanous Bmcweb APIs should call the mapper in cases where it's reasonably expected 24*e2415fa7SEd Tanous that multiple implementations exist (ex, CPU management, Sensors). 25