Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Nuwan Dias
There are several problems in allowing to edit the Swagger file directly. 1. We change it on new product releases. So now users have to find a way to merge whatever their changes when doing product upgrades. This is error prone. 2. The Swagger file is 100s of lines long and it has lots of

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Sanjeewa Malalgoda
On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote: > There are several problems in allowing to edit the Swagger file directly. > > 1. We change it on new product releases. So now users have to find a way > to merge whatever their changes when doing product upgrades. This is

Re: [Architecture] [APIM][C5] - Handling Broker request failure during Gateway event publishing

2017-05-09 Thread Srinath Perera
As Fazlan said, if we first publish and then only do API processing, it will remove the need to rollback. If the API processing failed after publishing, we can publish another event saying processing failed. --Srinath On Tue, May 9, 2017 at 11:06 AM, Fazlan Nazeem wrote: >

Re: [Architecture] [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

2017-05-09 Thread Srinath Perera
adding Prabath. Don't we have this level of permission checks though identity components? If we have to implement this, then if we can keep the model with only allow actions, it will simplify the model. --Srinath On Sat, May 6, 2017 at 12:45 AM, Ayyoob Hamza wrote: >

Re: [Architecture] Device Connectivity Graph for IoT Server & related concerns

2017-05-09 Thread Srinath Perera
+1 for auditing table On Mon, May 8, 2017 at 2:45 PM, Ayyoob Hamza wrote: > Hi Ruwan, > > +1 for this, Having the communication history through a common stream will > help us to build an analytics solution for health status, anomaly detection > .. etc. > > On Mon, May 8, 2017

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Nuwan Dias
Regarding adding entries to the config file, you don't need to even open the swagger file. What you need to do is to find the resource from the docs and enter it into the config file. By expecting a sys admin to edit the Swagger file my main worry is we're expecting the sys-admin to play with an

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Sanjeewa Malalgoda
On Tue, May 9, 2017 at 12:59 PM, Nuwan Dias wrote: > > > On Tue, May 9, 2017 at 12:26 PM, Sanjeewa Malalgoda > wrote: > >> >> >> On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote: >> >>> There are several problems in allowing to edit the

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Nuwan Dias
No Sanjeewa, in the method I'm proposing the system "will not break" even if someone goes and puts Japanese characters in the config file. That is by design. One design principle from 3.0.0 onwards is to have no migration script involved. In the method I'm proposing we avoid migration 100% (for

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Nuwan Dias
So it seems Sanjeewa's and my view points are clear on this. 1. Sanjeewa basically says let users (sys-admins) edit the Swagger file that define the product REST API. Objective is to avoid duplicating resource to scope mappings elsewhere. 2. I basically say maintain an optional config file so

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

2017-05-09 Thread Sanjeewa Malalgoda
On Tue, May 9, 2017 at 4:57 PM, Nuwan Dias wrote: > Regarding adding entries to the config file, you don't need to even open > the swagger file. What you need to do is to find the resource from the docs > and enter it into the config file. By expecting a sys admin to edit the >