- **status**: unassigned --> accepted
- **assigned_to**: Anders Bjornerstedt --> Hung Nguyen
- **Milestone**: future --> 5.0
---
** [tickets:#801] IMM: Canonicalize attributes presented by
OiCcbObjectModifyCallback**
**Status:** accepted
**Milestone:** 5.0
**Created:** Fri Feb 28, 2014 02:29 PM UTC by Anders Bjornerstedt
**Last Updated:** Fri Feb 28, 2014 02:29 PM UTC
**Owner:** Hung Nguyen
For OIs or appliers receiving ccb-callbacks, the handling of the modify-callback
can be particularly complex. This is due to the modify callback being defined
by SAF as faithfully presenting the same parameters as the originating
om-client
parameters provided over the om-api.
The ccbObjectModify operation allows for modifications expressed as changes
relative to the current state of attributes. This is of course acted on by
the imm-server resulting in an after-image for the modified object.
The callback to the oi or applier is currently of the same form, in general
requiring the oi/applier to (a) know the current state of the attributes of
the object or do an for appliers *unsafe* read and (b) to correctly compute
the transformation as defined by the imm-spec. Particularly the later is
asking quite a lot for the average oi/applier implementer.
Only for the "special applier" (see IMMSV README) is the modify callback
currently canonicalized to contain simply the replacement values, i.e. the
after operation image.
To simplify the task for oi's and appliers in handling modify callbacks,
we suggest that the modify-callback instead provides the after-modify-
operation-image of the attributes.
For regular OIs I suggest that only the values of the attributes actually
modified by this modify operation will be provided. For appliers the after
image of all writable attributes will be provided.
Note that this change is a fully backwards compatible change, because the
new callback format contaning just the replacement value resulting from the
operation must be logically equivalent to the set of all before-image and
operation variants resulting in this replacement value.
The only complication I can think of here is a potential performance issue
in pushing values to the callback that are actually unchanged. This is why
I think it is better that the main OI still gets only the replacement value
for attributes that actually have changed, or to be precise, where actually
operated on.
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
