I already responded with my overall design preference but had one point
in the chain I wanted to discuss a bit more.

On Wed, May 27, 2020 at 10:49:38PM +0530, Thomaiyar, Richard Marian wrote:
> 
> [Richard]: If we are choosing this option, then we can use the existing 
> Frudevice interface and use the PRODUCT_XYZ which is currently exposed. 
> Almost all the PLDM Fru content will match the IPMI FRU, except few like 
> SKU, version, description, Engineering_change_level & Vendor IANA (which 
> we can expose as new properties in the same interface) ??
> 
> i.e. PLDM PartNumber is nothing but PRODUCT_PART_NUMBER in IPMI Fru etc.

The current FruDevice interface is effectively a private dbus API
between EM and `fru-device` (which is also in the EM repo anyhow) and it
doesn't follow either our dbus practices nor widely accepted ones.  Here
are a few reasons:

    - FruDevice instances do not have the same properties.  Two
      different IPMI FRU types create a different set of properties, so
      you end up with dbus objects with a variety of interface layouts.

    - The properties exposed are not documented and differ stylistically
      from our existing, documented dbus objects.

Right now, if we need to implement another FruDevice provider, such as
will likely happen as Facebook implements our multi-host system, we have
to reverse engineer the code in `fru-device`.  Ideally this would be
refactored into a set of documented dbus interfaces under
`Inventory/Source/IPMI` (or some equally reasonable name) so others
could implement as needed.

-- 
Patrick Williams