#1651 imm: OiCcbObjectModifyCallback for appliers should include attributes that is not modified

[Hung Nguyen]

First, the reason for sending all values is to solve the initialization problem.
Ideally you would only have to send all values in the first callback for any given object and for any given attachement.
Once the OI/appplier has the current values for an object it would only need to get the replacement values for later callbacks.
The problem is that this is difficult to implement in the server.
So the practical solution is to always send all values.
This is how the special applier works.
It is also now suggested for regular appliers.

Second, one difference between appliers and OIs is that OIs do have some chance of almost dooing safe-read.
Since only one or zzero OIs can be attached for any given class/object, if zero is attached then ideally no CCB should
modify the object or insrances of the class. The problem is of course the idiotic default option specified by SAF
that allows the OM user to say IGNORE IF THERE IS NO OI ATTACHED.

If you use immcfg then this wil not happen because immcfg by default does not allow this.
Most OM applications I hope also do not use that option. It is visible in the syslogs if it is used as
a message saying that the oepration is unsafe.

Another difference between OIs and appliers is that OIs are supposed to VALIDATE the CCB.
This means that a "new" value for an attribute that is not "writable" causes a problem.
The OI must write code to check that the "new" proposed value is the same as the "old" value.
It is really a silly problem.

So the suggestion is to only send the after values for attributes that have actually changed value, for regaular OIs.
The main simpplification of #801 is still there for regular OIs, i.e. to only have to deal with replace.

You could argue that appliers should get the same protocol.
But for appliers the initialization problem is much more dificult.
Appliers have no way to perform a safe read and the detachmenet of an applier does not stop CCB processing.
In theory an appplier could itself set admin-owner over a set of objects or classes, but as you know the admin-owner concept is
not secure itself and the applier can only set admin-owner for objects that exist so it does noot cover object creates.
So appliers desperately need a safe way to initialize, even more so than regular OIs.

This ticket is separated from [#801]

[Hung Nguyen]

default 5.0

changeset: 7329:0f7b563c5405 [0f7b56]
tag: tip
user: Hung Nguyen hung.d.nguyen@dektech.com.au
date: Wed Mar 16 18:05:41 2016 +0700
summary: imm: Send all writable attributes to applier in OiCcbObjectModifyCallback [#1651]