Hi Anders, Below is Amf problems with this enhancements: 1. The code doesn't allow to modify some attributes, because those attributes/features are not supported yet. So, Amf will reject the modify callback with this feature. 2. REPLACE is used only for multi-valued attributes. For others, we are modifying the attributes as replacement. But there is no check whether the attributes has been modified with the same value. Hence there may be chances that the many triggers of change will occur at the same time(not desired). 3. Amf is rejecting REPLACE option for Initialized attributes(e.g. saAmfNGNodeList) as of now. So, modify callback will get rejected.
The similar issues exists in Log service, and others. So, it gives me impression that the this feature has application backward compatibility issues and need to modify Middleware and other User's applications. Thanks -Nagu > -----Original Message----- > From: Anders Bjornerstedt [mailto:[email protected]] > Sent: 30 November 2015 23:26 > To: Reddy Neelakanta Reddy Peddavandla > Cc: [email protected]; [email protected]; > Nagendra Kumar; [email protected]; [email protected] > Subject: Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented by > OiCcbObjectModifyCallback [#801] > > If I where to play the "devils advocate" and try hard to find some positive > argument for still supporting add and remove for ccb-modify in OI callbacks, > I guess it could be "performance". If we have a multivalued attribute X that > is "large" and want to add one element to the set/bag then of course > deleting > the whole set/bag X and recreating X+ (1element) could be argued to be > inefficient in execution. > > But then taking the stance of the devils devils advocate, which cancels the > devils, I would argue that such a performance argument should be ignored > because config data is not "big data" and config data is not updated > frequently. I would also say that having OIs support not just replace, but > also > add > and remove is an invitation for OI implementers to add redundant software > with the added risk of bugs that can make the OI representation of the data > deviate from the imm rep, without this always being trivially or quickly > detected. > > /AndersBj > > > >----Ursprungligt meddelande---- > >Från : [email protected] > >Datum : 30-11-2015 - 06:57 (GMT) > >Till : [email protected] > >Kopia : [email protected], [email protected], > [email protected], [email protected], > [email protected] > >Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented > by OiCcbObjectModifyCallback [#801] > > > >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=254741911&iu=/4140 _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
