Hi , Adding Nags, to know more on AMF dealing the modify callback and any impacts because of this enhancement for AMF.
Thanks, Neel. On Friday 27 November 2015 10:01 PM, Anders Bjornerstedt wrote: > Hi Neel, > > We dont need a new callback because the change is backwards compatible. > Yes OIs such as the AMF has code for dealing with delete and addoperations > for modify callbacks, but the AMF *must* also have code > for dealing with replace. > > The AMF-OI code for dealing with delete and add will just be obsolete code > when the 5.0 version of the API is used. > That should not be a problem. > I dont see any need for adding a new API if it has the same signature as the > old. > If there is a point it would *only* be to avoid having new OI implementers > adding useless code for handling delete and add operations. > But I think that simplification for new OIs could be communicated just via > documentation. > > > /AndersBj > > >> ----Ursprungligt meddelande---- >> Från : [email protected] >> Datum : 27-11-2015 - 13:36 (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, >> >> 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 >>>>>>>>> >> ------------------------------------------------------------------------------ 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
