Hi AndersBj, If canonicalizing the modify callback is done, then there are middleware services like amf, plm which uses SA_IMM_ATTR_VALUES_DELETE and SA_IMM_ATTR_VALUES_ADD for comparison and do operations based on this.
Instead of providing the canocicalizing attribute values in older callbacks, add a new callback for modify. like SaImmOiCcbObjectModifyCallbackT_3 a new callback for modify, for all attributes with OI latest(5.0) version. Thanks, Neel. On Thursday 26 November 2015 08:34 PM, Anders Bjornerstedt wrote: > Hi Neel, > > Eliminating add/delete and instead simply using replace is the canocicalizing > (or normal forming) the modify callback. > This is the whole point of #801. > > I dont follow you in what sense the "wrong" operation is sent to the OI. > The point is that any add or delete operation can be transformed to a replace > with the after value that would have been the result of an add or delete. > So the replace with the after value is equivalent in outcome. > > /AndersBj > > >> ----Ursprungligt meddelande---- >> Från : [email protected] >> Datum : 26-11-2015 - 13:29 (GMT) >> Till : [email protected] >> Kopia : [email protected], [email protected], >> [email protected], [email protected] >> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented by >> OiCcbObjectModifyCallback [#801] >> >> Hi AndersBj, >> >> Comments below. >> >> Thanks, >> Neel. >> >> On Thursday 26 November 2015 05:03 PM, Anders Bjornerstedt wrote: >>> One more thing about appliers and #801. >>> >>> The protocol for the *special applier* function must not be altered by #801. >> Yes, the special applier protocol should not be altered. >> But, I have a concern the way the patch is published(which is taken from >> special appliers): >> If all the attributes need to be delivered in the callback, why >> ADD/DELETE is changed to REPLACE operation. >> The behavior of changing ADD/DELETE to REPLACE operation will send wrong >> modify operations to OI/applier. >>> /AndersBj >>> >>> >>>> ----Ursprungligt meddelande---- >>>> Från : [email protected] >>>> Datum : 26-11-2015 - 09:52 (WET) >>>> Till : [email protected] >>>> Kopia : [email protected], [email protected], >>>> [email protected], [email protected] >>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented >>>> by OiCcbObjectModifyCallback [#801] >>>> >>>> Hi Neel, >>>> >>>> Ok so we are discussing only the regular OI case. >>>> >>>> Concerning point (1) regular OIs and adding or not adding unchanged >>>> attribute values, I suggest that this could be made an option. >>>> Perhaps setting the OI library version to this latest (5.0 ?) version >>>> could be used as the discriminator. >> what are the thoughts on SaImmOiCcbObjectModifyCallbackT_3 a new >> callback for modify, for all attributes . >>>> The advantage with this aproach is that it releives also regular OIs from >>>> the "initialization problem", i.e. the problem that a newly started >>>> OI process faces: How to get the initial state of its config data? The SAF >>>> spec provides no explicit solution for this problem, most liklely >>>> because they did not think about it and certainly because SAF did not have >>>> any reference implementation for the spec before freezing the spec. >>>> The solution the OpenSAF IMM documentation proposes is for the OI to set >>>> admin-owner to some hopefully exclusive value while reading the >>>> data using unsafe read (search and accessor get). This is not really a >>>> satisfactory solution since it is not 100% guaranteed to provide isolation. >>>> It works in practice (most of the time) because config data is in general >>>> updated with low frequency and most OM users *hopefully*, set the CCB >>>> flags to correctly to require OI presence. But "hope" and "rarely" are not >>>> terms that should be asssociated with avoiding inconsistent coonfig data. >>>> >>>> Concerning (b) waste of resource, I agree that this is the case, >>>> particularly if the config data is bulky. So one solution here could be to >>>> only >>>> add all the unchanged attribute values in the *first* callback made to an >>>> OI that has just attached. This is an impprovement sugggestion to [#801]. >>>> It could just as welll be used also for appliers. >> The book keeping of objects to a particular OI/applier, will become an >> additional responsibility in IMM database. >>>> Converning point (c): I would say that how light or heavy an appplier vs >>>> OI is is completely up to the developers of these functions. >>>> They should preferrably get the same callbacks with the same contents as >>>> the OI unless there is a very good reason to break that rule. >>>> The reason is the old KISS rule. Not folowing it will result in the >>>> average OI/applier developer getting it wrong. As we all know the average >>>> developer does not read much if any documentation, unless they really run >>>> into problems... >>>> >>>> Concerning appliers in the form supported by OpenSAF not being SAF >>>> standard, that is correct. >>>> But that of course does not mean there are no strict rules. The applier >>>> concept must strictly obey the specification that is documented by OpenSAF. >>>> So I of course interpret what you are saying as not that there are no >>>> strict rules for appliers, but that OpenSAF is free to set the rules. >>>> OpenSAF has set the current strict rules for appliers. >> I agree, that the appliers and OI callbacks must have same information. >>>> Thanks, >>>> >>>> /AndersBj >>>> >>>> >>>>> ----Ursprungligt meddelande---- >>>>> Från : [email protected] >>>>> Datum : 26-11-2015 - 07:07 (GMT >>>>> Till : [email protected] >>>>> Kopia : [email protected], [email protected], >>>>> [email protected], [email protected] >>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented >>>>> by OiCcbObjectModifyCallback [#801] >>>>> >>>>> Hi AndersBj, >>>>> >>>>> 1)For the OI, only the attribute values that have actually being changed >>>>> must be included in the modify callback. >>>>> Even though the change is backward compatible, The following can be the >>>>> reasons for not sending unchanged values : >>>>> a. It follows SAF spec >>>>> b. waste of resources. >>>>> c. OI are not light as appliers, can maintain the information on >>>>> modification objects OI are expecting. >>>>> >>>>> 2) For the appliers, the change may be allowed: >>>>> a. most of the appliers are light-weight and may not have previous >>>>> information on the object attributes >>>>> b. Appliers are not SAF standard (no strict rules) >>>>> c. changing of modify type from ADD/DELETE to REPLACE may not have any >>>>> effects on appliers, as they are just information receivers. >>>>> >>>>> Thanks, >>>>> Neel. >>>>> >>>>> >>>>> >>>>> On Thursday 26 November 2015 02:22 AM, Anders Bjornerstedt wrote: >>>>>> Hi Neel, >>>>>> >>>>>> Writing from the sidelines :-) >>>>>> >>>>>> I dont see any backwards compatibility issue as long as the OI callback >>>>>> contains information that is equivalent in outcome/result to the effect >>>>>> of the execution of the OM input. >>>>>> As long as the callback contains what *could* have been the OM input and >>>>>> the resulting value change is exactly the same, it should be ok. >>>>>> >>>>>> Remembe ralso that the OM users and the OI/application are decoupled. >>>>>> >>>>>> Only the attribute values that have actually been changed must be >>>>>> included in the OI callback. >>>>>> Including unchanged values is not strictly necessary and could be argued >>>>>> is a waste of resources. >>>>>> Still that would not be a backwards compatibility issue. >>>>>> >>>>>> Thanks >>>>>> AndersBj >>>>>> >>>>>> >>>>>>> ----Ursprungligt meddelande---- >>>>>>> Från : [email protected] >>>>>>> Datum : 25-11-2015 - 11:25 (GMT) >>>>>>> Till : [email protected], [email protected], >>>>>>> [email protected] >>>>>>> Kopia : [email protected] >>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >>>>>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>> >>>>>>> Hi Hung, >>>>>>> >>>>>>> The following is required by this ticket: >>>>>>> >>>>>>> 1. The saImmOiCcbObjectModifyCallback for implementer must pass only >>>>>>> the values of the attributes actually >>>>>>> modified by this modify operation will be provided. That is no deviation >>>>>> >from current implementation for OI. >>>>>>> The present patch changes ADD/DELETE to REPLACE for OI also. >>>>>>> >>>>>>> 2. The enhancement is about to pass "all writable after-image >>>>>>> attributes" to the saImmOiCcbObjectModifyCallback for appliers. >>>>>>> while passing change modify type ADD/DELETE to REPLACE. >>>>>>> >>>>>>> The present patch passes only the modification attributes that are >>>>>>> modified by the modify Ccb operation. >>>>>>> >>>>>>> >>>>>>> I have to NACK the patch. >>>>>>> >>>>>>> /Neel. >>>>>>> >>>>>>> >>>>>>> On Friday 09 October 2015 04:45 PM, Hung Nguyen wrote: >>>>>>>> osaf/services/saf/immsv/immnd/ImmModel.cc | 27 >>>>>>>> +++++++++++++++++++++++++++ >>>>>>>> 1 files changed, 27 insertions(+), 0 deletions(-) >>>>>>>> >>>>>>>> >>>>>>>> This patch modifies the content of incoming IMMND_EVT_A2ND_OBJ_MODIFY >>>>>>>> messages. >>>>>>>> If the modType is SA_IMM_ATTR_VALUES_ADD or SA_IMM_ATTR_VALUES_DELETE, >>>>>>>> it will be converted to SA_IMM_ATTR_VALUES_REPLACE and the values of >>>>>>>> the attr-mod will be the values in the after image. >>>>>>>> >>>>>>>> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>> b/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>> @@ -8705,6 +8705,33 @@ ImmModel::ccbObjectModify(const ImmsvOmC >>>>>>>> if(err != SA_AIS_OK) { >>>>>>>> break; //out of for-loop >>>>>>>> } >>>>>>>> + >>>>>>>> + if (p->attrModType != SA_IMM_ATTR_VALUES_REPLACE) { >>>>>>>> + osafassert(p->attrValue.attrValuesNumber); >>>>>>>> + /* Free attribute values of the attr-mod */ >>>>>>>> + immsv_evt_free_att_val_raw(&(p->attrValue.attrValue), >>>>>>>> + p->attrValue.attrValueType); >>>>>>>> + if (p->attrValue.attrValuesNumber > 1) { >>>>>>>> + immsv_free_attr_list_raw(p->attrValue.attrMoreValues, >>>>>>>> + p->attrValue.attrValueType); >>>>>>>> + p->attrValue.attrMoreValues = NULL; >>>>>>>> + } >>>>>>>> + p->attrValue.attrValuesNumber = 0; >>>>>>>> + >>>>>>>> + TRACE("Canonicalizing attr-mod for attribute '%s'", >>>>>>>> attrName.c_str()); >>>>>>>> + p->attrModType = SA_IMM_ATTR_VALUES_REPLACE; >>>>>>>> + if (!attrValue->empty()) { >>>>>>>> + attrValue->copyValueToEdu(&(p->attrValue.attrValue), >>>>>>>> + (SaImmValueTypeT) >>>>>>>> p->attrValue.attrValueType); >>>>>>>> + if (attrValue->extraValues()) { >>>>>>>> + osafassert(attrValue->isMultiValued()); >>>>>>>> + ImmAttrMultiValue* multiVal = (ImmAttrMultiValue >>>>>>>> *) attrValue; >>>>>>>> + >>>>>>>> multiVal->copyExtraValuesToEdu(&(p->attrValue.attrMoreValues), >>>>>>>> + (SaImmValueTypeT) >>>>>>>> p->attrValue.attrValueType); >>>>>>>> + } >>>>>>>> + p->attrValue.attrValuesNumber = 1 + >>>>>>>> attrValue->extraValues(); >>>>>>>> + } /* else, attrValuesNumber is already set to 0 */ >>>>>>>> + } >>>>>>>> }//for (p = ....) >>>>>>>> >>>>>>>> // Prepare for call on PersistentBackEnd >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Go from Idea to Many App Stores Faster with Intel(R) XDK >>>>>>> Give your users amazing mobile app experiences with Intel(R) XDK. >>>>>>> Use one codebase in this all-in-one HTML5 development environment. >>>>>>> Design, debug & build mobile apps & 2D/3D high-impact games for >>>>>>> multiple OSs. >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >>>>>>> _______________________________________________ >>>>>>> Opensaf-devel mailing list >>>>>>> [email protected] >>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>> >> ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
