Hi Anders,
Thanks for your reply.
So, if this feature is implemented as A.2.18(say), it will have no impact on
Amf or any other applications(As Amf is initialized with A.2.11 as of now).
But, let us say, later on, Imm implements another feature with versions A.2.18
or A.2.19 and Amf or any other applications need it.
Then either Amf has to go to version A.2.18 or A.2.19 and it has to go for many
changes in the code because
ticket #801 has been already implemented in A.2.18 or A.2.19.
And say Amf doesn't need this feature of #801.
So, what are the ways Amf can isolates itself from using #801 but want to use
another feature implemented
with version A.2.18 or A.2.19.
Thanks
-Nagu
> -----Original Message-----
> From: Anders Bjornerstedt [mailto:[email protected]]
> Sent: 01 December 2015 20:47
> To: Nagendra Kumar
> Cc: [email protected]; [email protected]; Reddy Neelakanta
> Reddy Peddavandla; [email protected]; opensaf-
> [email protected]
> Subject: Re: RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes
> presented by OiCcbObjectModifyCallback [#801]
>
> Hi Nags,
>
> The AMF should simply not change its IMMA-OI interface version to the next
> version (A.2.17 if I am not mistaken).
> As long as it keeps the IMMA-OI version to its current version there is no
> change in behavior and there is not problem.
>
> Regarding point (1) I assume you are talking about the proposal in #801 to
> send all attribute values in the first create or modify callback for
> any particular object sent to an OI that has just attached. I am not sure Hung
> has implemented that feature in #801.
> In any case the basic proposal for #801 is to only send the after values for
> attributes that are actually being proposed for change in a modify operation.
>
> Regarding point (2) it sounds really strange. For single valued attributes I
> would say REPLACE is the operation that makes most sense t o use all the
> time.
> It never occured to me that any one would use add and remove on a single
> valued attribute, except for the special case to go from no value to one value
> or vice versa, but replace could also be used for that, so why use add and
> remove ?
> To me add and remove only really make sense on multi valued attributes.
> I know the SAF IMM spec talks about doing add and remove on single valued
> attributes in the sense of adding or removing the attribute as such
> from an instance (even though the attribute is still defined in the class!).
> This
> very strange feature has never been supported by the OpenSAF IMM
> and so we may have a discrepancy between AMF and IMM here of precisely
> the kind that I was warning about and for which enhancement #801 is
> partly intended. Example: If you do remove on a single valued attribute X in
> object A and after that try to fetch attribute X using an acccessor get on A,
> do you expect to get ERR_NOT_EXIST ? The attribute does exist according to
> the class definition ! If you do expect to get ERR_NO_EXIST then you will be
> disapointed.
> The IMM will not reply with ERR_NOT_EXIST but with the empty value (if the
> value for the attribute is currently empty). I have never understood the
> point in allowing both the empty value for an attribute AND the notion of the
> attribute not *existing* in the instance of a class where the class declares
> the attribute to exist. So the OpenSAF IMM does not support that notion of
> both a null value and a super null value.
> All this complexity in the SAF IMM data model for expressing the same kind
> of modification in seeral ways is not helping anyone. It is only causing
> confusion and dislocation in what is supported, what is comprehended by
> OM users andwhat is comprehended by OI users.
>
> Regarding point (3) I have touble folowing what you are saying (which is sad
> when I have worked with the IMM for so many years) The
> SA_IMM_ATTR_INITIALIZED flag,
> which I assume you are referring to, means only that at object creation time,
> the attribute must have a value assigned to it. That is the attribute is not
> allowed to be
> empty at object create time. The flag does not mean the value can not be
> changed/updated (!) and asuming that it *is* to be updated which it is
> allowed to be
> according to boththe IMM spec and the SAF spec, then you should
> preferrably use replace, so that the attribute has a value at all times. If
> you
> for some strange reason
> prefered to acheive the same replacement by doing the more complex
> excercise of first a remove and then an add, the attribute would be empty
> after the remove and
> before the add.
>
> Anyway to sumarize: If >>we<< i.e. us developers of OpensAF have trouble
> agreeing on the semantics of the SAF model operations, then what is to be
> expected of users ?
> So we really do need to simplify where simplification is possible and
> particularly where there is absoolutely no loss in expressive power after
> doing the simplification.
> And as I say this change is introduced in the next version. Any OI that does
> not set the version to this version will get the old behvior.
> The new version does not change behavior in any way that violates the SAF
> spec. Thus all the cases described here where the AMF will report problems is
> due to
> problems in the AMF relative to supporting the *current* SAF spec. Using
> replcae on a single valued attribue is alllowed according to the SAF spec and
> having the AMF
> being more restrictive than the IMM on what IMM operations are allowed in
> general is not a good idea. The AMF or any OI should of course be more
> retrictive than
> the IM in what it allows according to *semantic* rules. Such semantic rules
> are always to be evalueated in the completed callback, not in the operation
> callbacks.
>
> /AndersBj
>
>
> >----Ursprungligt meddelande----
> >Från : [email protected]
> >Datum : 01-12-2015 - 10:26 (GMT)
> >Till : [email protected], [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 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
