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 >>>>> >>> ------------------------------------------------------------------------------ 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
