It doesn't make sense to remove the non-XML C++ APIs. Most C++ programmers will not want to be forced into building XML to do mundane things, and would normally end up writing something similar to the existing C++ API on top of the XML one. We should consider the XML APIs to be a sort of XML binding. If we need to revisit making the C++ APIs simpler that's a different topic, but let's not throw the baby out with the bath water.
Regarding deprecation: you can't avoid it by merely using XML. While XML may be more graceful at deprecation of interfaces than C or C++, there is always a contract between the API and its consumer. We would still need to support old versions of the XML contract for 4 releases. -Josh *Josh Spain, Director of Engineering, Affinegy* 1705 S. Capital of Texas Hwy, Ste. 310, Austin, TX, 78746 512.535.1700 [email protected] http://affinegy.com On Tue, Aug 16, 2016 at 2:00 PM, Pawel Winogrodzki <[email protected]> wrote: > I confirm. My idea right now is to change that method’s signature to > exactly what Claim() is using for manifests. There is also a separate one > for signing both manifests and certificates in XML format. > > > > Pawel > > > > *From:* Daniel Mihai > *Sent:* Tuesday, August 16, 2016 7:58 AM > *To:* George Tang <[email protected]> > *Cc:* Aaron Vernon <[email protected]>; [email protected]; Lioy, > Marcello <[email protected]>; Josh Spain <[email protected]>; > Jorge Martinez <[email protected]>; allseen-core <allseen-core@lists. > allseenalliance.org>; Pawel Winogrodzki <[email protected]> > *Subject:* RE: [Allseen-core] Removing non-XML-based public C++ APIs > > > > InstallManifests is one of a few APIs that Pawel identified a couple days > ago as “need to revisit”. Let’s discuss it in the next week or so, when > Pawel is ready. > > > > I believe the most common way of installing manifests is by using Claim() > – and Claim is available already: > > > > QStatus Claim(const qcc::KeyInfoNISTP256& certificateAuthority, > > const qcc::GUID128& adminGroupId, > > const qcc::KeyInfoNISTP256& adminGroup, > > const qcc::CertificateX509* identityCertChain, size_t > identityCertChainCount, > > AJ_PCSTR* manifestsXmls, size_t manifestsCount); > > > > Dan > > > > *From:* George Tang [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, August 16, 2016 7:46 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 <allseen-core@lists. > allseenalliance.org> > *Subject:* Re: [Allseen-core] Removing non-XML-based public C++ APIs > > > > 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]> 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 > <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] > https://lists.allseenalliance.org/mailman/listinfo/allseen-core > > >
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
