Does this add a dependency towards libstdc++ from the agent library? If 
it does, I think it would be problematic. It could interfere with an 
application which is also written in C++ but linked against a difference 
C++ standard library (either a different version of libstdc++, or a 
completely different implementation like e.g. libc++).

/ Anders Widell

On 02/08/2016 04:37 PM, Hans Nordebäck wrote:
> Hi Praveen, Nagu, Mathi and Anders,
>
> Any comments on this patch? As Gary mentions below,  it would e.g. make 
> supporting long DN a lot easier. /Thanks HansN
>
>
>
> -----Original Message-----
> From: Gary Lee [mailto:[email protected]]
> Sent: den 1 februari 2016 09:49
> To: Hans Nordebäck
> Cc: [email protected]; [email protected]; Anders Widell; Minh 
> Chau H; [email protected]; [email protected]
> Subject: Re: [PATCH 0 of 1] Review Request for amfa: Divide amf api functions 
> in a thin C layer and use C++ for implementation [#1673]
>
> Hi Hans
>
> I think it would be very, very nice if we got rid of SaNameT in 
> libs/common/osaf, and replaced it with std::string.
>
> As you know, the data structures defined here are used by the agent, director 
> and node director.
>
> There is a lot of code that copies and frees various messages (both in the 
> common lib and director). It would make supporting long DN a lot easier, if 
> we didn’t have to worry about SaNameT, and ‘deep copying’.
>
> Thanks
> Gary
>
>> On 30 Jan 2016, at 12:39 AM, Hans Nordeback <[email protected]> 
>> wrote:
>>
>> Summary: amfa: Divide amf api functions in a thin C layer and use C++
>> for implementation Review request for Trac Ticket(s): #1673 Peer
>> Reviewer(s): Mathi, AndersW, Praveen, Nagu, Gary, Minh Pull request
>> to:
>> Affected branch(es): default
>> Development branch: default
>>
>> --------------------------------
>> Impacted area       Impact y/n
>> --------------------------------
>> Docs                    n
>> Build system            n
>> RPM/packaging           n
>> Configuration files     n
>> Startup scripts         n
>> SAF services            n
>> OpenSAF services        n
>> Core libraries          y
>> Samples                 n
>> Tests                   n
>> Other                   n
>>
>>
>> Comments (indicate scope for each "y" above):
>> ---------------------------------------------
>> <<EXPLAIN/COMMENT THE PATCH SERIES HERE>>
>>
>> changeset 20dec14de18f2f5d4095c6d2ef703893e26723d7
>> Author:      Hans Nordeback <[email protected]>
>> Date:        Fri, 29 Jan 2016 14:35:14 +0100
>>
>>      amfa: Divide amf api functions in a thin C layer and use C++ for
>>      implementation [#1673]
>>
>>      The amf agent part is implemented in C and shares C data structures with
>>      amfd and amfnd, e.g. libs/common/osaf. It would be benficial if the amf
>>      agent could be split into two parts, one thin C layer that passes the 
>> call
>>      to C++ for the implementation. Then it will be significally easier to
>>      convert libs/common/osaf structures and functions to C++ and remove 
>> e.g. the
>>      use of SaNameT and support long DN. The C++ usage at the agent could be
>>      limited to follow C++98 standard to ease acceptance for applications. A
>>      patch is sent out with this change and comments are appreciated.
>>
>>
>> Added Files:
>> ------------
>> osaf/libs/agents/saf/amfa/include/amf_agent.h
>>
>>
>> Complete diffstat:
>> ------------------
>> osaf/libs/agents/saf/amfa/Makefile.am          |     2 +-
>> osaf/libs/agents/saf/amfa/ava_api.c            |  4207 
>> ++++++++++++++++---------------
>> osaf/libs/agents/saf/amfa/ava_init.c           |     2 +-
>> osaf/libs/agents/saf/amfa/include/amf_agent.h  |    96 +
>> osaf/libs/agents/saf/amfa/include/ava.h        |     7 +
>> osaf/libs/agents/saf/amfa/include/ava_cb.h     |     7 +
>> osaf/libs/agents/saf/amfa/include/ava_dl_api.h |     7 +
>> osaf/libs/agents/saf/amfa/include/ava_hdl.h    |     7 +
>> osaf/libs/agents/saf/amfa/include/ava_mds.h    |     7 +
>> 9 files changed, 2304 insertions(+), 2038 deletions(-)
>>
>>
>> Testing Commands:
>> -----------------
>> <<LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES>>
>>
>>
>> Testing, Expected Results:
>> --------------------------
>> <<PASTE COMMAND OUTPUTS / TEST RESULTS>>
>>
>>
>> Conditions of Submission:
>> -------------------------
>> <<HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC>>
>>
>>
>> Arch      Built     Started    Linux distro
>> -------------------------------------------
>> mips        n          n
>> mips64      n          n
>> x86         n          n
>> x86_64      y          y
>> powerpc     n          n
>> powerpc64   n          n
>>
>>
>> Reviewer Checklist:
>> -------------------
>> [Submitters: make sure that your review doesn't trigger any
>> checkmarks!]
>>
>>
>> Your checkin has not passed review because (see checked entries):
>>
>> ___ Your RR template is generally incomplete; it has too many blank entries
>>     that need proper data filled in.
>>
>> ___ You have failed to nominate the proper persons for review and push.
>>
>> ___ Your patches do not have proper short+long header
>>
>> ___ You have grammar/spelling in your header that is unacceptable.
>>
>> ___ You have exceeded a sensible line length in your headers/comments/text.
>>
>> ___ You have failed to put in a proper Trac Ticket # into your commits.
>>
>> ___ You have incorrectly put/left internal data in your comments/files
>>     (i.e. internal bug tracking tool IDs, product names etc)
>>
>> ___ You have not given any evidence of testing beyond basic build tests.
>>     Demonstrate some level of runtime or other sanity testing.
>>
>> ___ You have ^M present in some of your files. These have to be removed.
>>
>> ___ You have needlessly changed whitespace or added whitespace crimes
>>     like trailing spaces, or spaces before tabs.
>>
>> ___ You have mixed real technical changes with whitespace and other
>>     cosmetic code cleanup changes. These have to be separate commits.
>>
>> ___ You need to refactor your submission into logical chunks; there is
>>     too much content into a single commit.
>>
>> ___ You have extraneous garbage in your review (merge commits etc)
>>
>> ___ You have giant attachments which should never have been sent;
>>     Instead you should place your content in a public tree to be pulled.
>>
>> ___ You have too many commits attached to an e-mail; resend as threaded
>>     commits, or place in a public tree for a pull.
>>
>> ___ You have resent this content multiple times without a clear indication
>>     of what has changed between each re-send.
>>
>> ___ You have failed to adequately and individually address all of the
>>     comments and change requests that were proposed in the initial review.
>>
>> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>>
>> ___ Your computer have a badly configured date and time; confusing the
>>     the threaded patch review.
>>
>> ___ Your changes affect IPC mechanism, and you don't present any results
>>     for in-service upgradability test.
>>
>> ___ Your changes affect user manual and documentation, your patch series
>>     do not contain the patch that updates the Doxygen manual.
>>



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to