In today's Core WG meeting we decided that:

1.       We'll proceed with the API changes described in the two attachments.

2.       We'll remove AddApplicationStateRule, rather than just marking it 
deprecated.

3.       We'll investigate the feasibility of removing the Rule and similar 
classes from the AllJoyn public SDK. We're considering replacing those classes 
with easier to use and maintain XML-based APIs.

Step #3 will require a separate proposal and discussion in the Core WG.

Please speak up with any questions or feedback before February 4th. We plan to 
implement this plan starting that day.

Thanks everyone!

From: Daniel Mihai
Sent: Wednesday, January 27, 2016 2:05 PM
To: Pawel Winogrodzki <[email protected]>; 
[email protected]; [email protected]; 
[email protected]; Dave Thaler <[email protected]>; Lioy, Marcello 
<[email protected]>; Malsbary, Todd <[email protected]>
Cc: Arvind Padole <[email protected]>
Subject: RE: New C++ API and C wrappers

Hi everyone,

We would like to discuss in the Core WG meeting tomorrow, and hopefully get 
approved, the changes proposed by Pawel.

Thanks,
Dan

From: Pawel Winogrodzki
Sent: Wednesday, January 20, 2016 5:44 PM
To: 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>; Dave Thaler 
<[email protected]<mailto:[email protected]>>
Cc: Daniel Mihai 
<[email protected]<mailto:[email protected]>>; Arvind Padole 
<[email protected]<mailto:[email protected]>>
Subject: New C++ API and C wrappers

Hi,

I'm a new dev at Microsoft working with Daniel Mihai. We would like to 
introduce wrappers for the C++ APIs responsible for Security 2.0 support plus a 
few C++ APIs that would allow to set manifest templates and ACLs from XMLs.

Please speak up with any questions or feedback.


1.       The new C++ APIs would be:

a.       PermissionPolicy::CreateManifestFromXml - this will create a list of 
rules that can be passed to the existing API to set the app's manifest template.

b.       PermissionPolicy::CreateManifestXmlFromRules - the reverse of the 
above method.

c.       PermissionConfigurator::SetPermissionManifestFromXml - allows to set 
the manifest template from an XML.

d.       PermissionPolicy::CreatePolicyFromXml - will set the PermissionPolicy 
contents from an XML.

2.       C wrappers for the following C++ APIs:

a.       BusAttachment:

                                                               i.      
GetPermissionConfigurator;

                                                             ii.      
RegisterApplicationStateListener;

                                                           iii.      
UnregisterApplicationStateListener;

                                                           iv.      
AddApplicationStateRule;

                                                             v.      
RemoveApplicationStateRule;

b.       PermissionConfigurator:

                                                               i.      
GetApplicationState;

                                                             ii.      
SetApplicationState;

                                                           iii.      
GetClaimCapabilities;

                                                           iv.      
SetClaimCapabilities;

                                                             v.      
GetClaimCapabilityAdditionalInfo;

                                                           vi.      
SetClaimCapabilityAdditionalInfo;

                                                          vii.      
SetPermissionManifestFromXml - one of the new APIs from #1;

c.       ApplicationStateListener:

                                                               i.      State 
callback - for now will accept key information encoded in PEM format.

                                                             ii.      
Constructor and destructor;

d.       SecurityApplicationProxy:

                                                               i.      
Constructor and destructor;

                                                             ii.      Claim - 
input keys and certs will be encoded in PEM format.

                                                           iii.      
GetManifestTemplate (plus a destructor function for the result of this wrapper) 
- will return the template in the XML format.

                                                           iv.      
GetApplicationState;

                                                             v.      
GetClaimCapabilities.

                                                           vi.      
GetClaimCapabilitiesAdditionalInfo;

                                                          vii.      
UpdatePolicy;

                                                        viii.      
UpdateIdentity;

                                                            ix.      
InstallMembership;

                                                             x.      Reset;

                                                            xi.      
ResetPolicy;

                                                          xii.      
GetEccPublicKey (plus a destructor function for the result of this wrapper);

For all of these I will also write unit tests.

Thanks,
Pawel Winogrodzki

Attachment: APIChanges_27_01_2016.pptx
Description: APIChanges_27_01_2016.pptx

--- Begin Message ---
Hi,



Currently after registering the first ApplicationStateListener with the 
BusAttachment we have to call AddApplicationStateRule afterwards in order to 
start watching for the "State" signals. Similarly when you want to unregister 
the last listener you remove the rule. I think it would be a lot easier and 
natural to just register/unregister the listener and have all of the rule 
adding/removal handled automatically.



Please let me know is there a reason for these two pairs to be handled 
separately? If not I think we could just handle the rules inside the 
register/unregister methods and deprecate Add/RemoveStateRule. I've created a 
bug<https://jira.allseenalliance.org/browse/ASACORE-2683> for that, in case we 
want to have it fixed.



Thanks,

Pawel Winogrodzki


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

Reply via email to