On 04/02/2014 12:13 PM, Pavel Březina wrote:> On 03/31/2014 01:18 PM,
Jan Safranek wrote:
> You may consider subclassing CIM_EnabledLogicalElement for
> LMI_SSSDProcess as it provides enabled/disabled/change state
> functionality.
>
> It depends how CIM-ish (=ugly) you want to be. There is whole heap of
> predefined classes, which may resemble something you are designing.
> Remember, you do not need to implement all properties/methods from the
> CIM classes, just those you find usable. It's hard to find appropriate
> CIM class to subclass, following links may be useful:
>
>
http://schemas.dmtf.org/wbem/cim-html/2.40.0+/
>
http://dmtf.org/sites/default/files/cim/cim_schema_v2400/cim_schema_2.40....
>
I must say I'm having moral issues inheriting from a class where I won't
implement most of its part. Is it really a common practice? I have
chosen to stay with CIM_ManagedElement for this version.
Welcome to CIM world of utterly complex classes :). It's common practice
to implement only 'Required' properties. And there are very little of
them. Anyway, CIM_ManagedElement will do just fine.
Out of curiosity, does SSSD already have a configuration API, e.g. on
DBus or as a library? Then I would suggest to throw away all DMTF
complexity and rewrite the API 1:1 to CIM - you have only one API to
document, available through two different access protocols, DBus/library
for local and CIM for remote configuration.
Jan