Actually you were right: SecurityApplicationProxy::InstallManifests is an API 
we need to revisit. The one you see in alljoyn_c works just in-proc, not over 
the network (PermissionConfigurator::InstallManifests in in-proc).

Dan

From: George Tang [mailto:[email protected]]
Sent: Tuesday, August 16, 2016 7:56 AM
To: Daniel Mihai <[email protected]>
Cc: Aaron Vernon <[email protected]>; [email protected]; Lioy, Marcello 
<[email protected]>; Josh Spain <[email protected]>; Jorge Martinez 
<[email protected]>; allseen-core <[email protected]>
Subject: Re: [Allseen-core] Removing non-XML-based public C++ APIs

Hi Dan,

My bad, I didn't look in alljoyn_c/inc/alljoyn_c.

George

On Tue, Aug 16, 2016 at 9:45 AM, George Tang 
<[email protected]<mailto:[email protected]>> wrote:
Hi Dan,

For these Security 2.0 changes, there are functions in SecurityApplicationproxy 
that don't seem to have a replacement function that uses a character pointer 
instead, like

InstallManifests(const Manifest* manifest, size_t manifestcount)

Would making manifest private make this function unusable?

Thanks,
George

On Mon, Aug 15, 2016 at 8:48 PM, Daniel Mihai via Allseen-core 
<[email protected]<mailto:[email protected]>>
 wrote:
Several months ago, we decided in the Core WG to start adding a set of new 
Public Security 2.0 C++ APIs, based on XML strings. For example, instead of the 
older:

QStatus UpdatePolicy(const PermissionPolicy& policy);

we added:

QStatus UpdatePolicy(const char* policyXml);

The older method requires having Public classes such as PermissionPolicy, Rule, 
Peer, Marshaller, DefaultPolicyMarshaller, Manifest, etc. These Public classes 
and methods are harder to maintain. For example, when Core needs to add or 
remove a Public method parameter, they have to go through a cumbersome Public 
API deprecation process, that takes years to complete.

We are now ready to start moving the older, non-XML-based, methods and classes 
out of Public, into Private.  If we succeed, a Security Manager app will not be 
able to use directly those classes/methods anymore. Please speak up in case you 
have questions or other type of feedback about this plan. 
(https://jira.allseenalliance.org/browse/ASACORE-2736)

The XML-based APIs can be somewhat harder to use when developing a Security 
Manager app. For example, a Security Manager app might have to:

-          Parse on its own the XML string coming from GetManifestTemplate, and

-          Construct on its own an XML string used as parameter for UpdatePolicy
At MSFT, we used msxml APIs for parsing. I guess other Security Manager vendors 
might use libxml2 or a similar library.

If you are looking for the set of Security 2.0 C++ APIs that we expect will 
remain Public, please take a look at alljoyn_c\inc\alljoyn_c. The C APIs are 
already using just the XML APIs.

Dan


_______________________________________________
Allseen-core mailing list
[email protected]<mailto:[email protected]>
https://lists.allseenalliance.org/mailman/listinfo/allseen-core


_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core

Reply via email to