Re: [Architecture] Restructuring Device Type Plugins for IoT

@Dilan, The idea here is that things like the transports adapters and the appm-connector are modular plugins that are just complementing the CDMF which is s framework. The framework does not necessarily need these to function and perform its core tasks. Hence these should evolve/get added

[Architecture] SNMP Connector

Hi, I have planned to implement the SNMP connector. Simple Network Management Protocol (SNMP) is a widely used protocol for monitoring network devices such as servers, printers, hubs, switches, and routers on an IP network. Connector will have the following operation: snmpGet():- It is

Re: [Architecture] Restructuring Device Type Plugins for IoT

Hi Ruwan, How about having a UI for the plugin deployment? So plugins can be installed and uninstalled via the UI like how we install/uninstall features in the carbon console. On Tue, Nov 22, 2016 at 9:59 PM, Dilan Udara Ariyaratne wrote: > Hi Ruwan, > > Why would not

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

Hi Dilan, > Does this mean we can basically have a ready-to-use device plug-in > implementation, just by configuring a descriptor file ? > Yes thats the idea, In here the plugin means the osgiService which contains the definition of the device type. we found from the existing device type that it

Re: [Architecture] Restructuring Device Type Plugins for IoT

Hi Ruwan, Why would not analytics be inside a particular device type ?, this is in fact the idea provided in [1]. And also, if these Input/Output transport adapters and extensions for MB/APP-M are in common to any device type, cannot we move them down to carbon-device-mgt platform layer ?

Re: [Architecture] SMPP Connector Improvement

Hi Biruntha, 1. What is the reason us to provide the support for "query_sm", most of the SMSC does not provide the support for this. I wonder we ever need to support it. 2. When we maintain the SMPP session in the pool, we have to manage the idle sessions. We need to send "enquire_link"

Re: [Architecture] SMPP Connector Improvement

Hi Biruntha, There can be multiple gateways based on client configuration and for multiple tenants. We need to reuse only the sessions for the given service provider and tenant. I guess you are considering those as well? On Tue, Nov 22, 2016 at 12:14 PM, Biruntha Gnaneswaran

Re: [Architecture] SMPP Connector Improvement

yes Malaka, i'm considering that also. Biruntha Associate Software Engineer WSO2 Email : birun...@wso2.com Linkedin : https://lk.linkedin.com/in/biruntha Mobile : +94773718986 On Tue, Nov 22, 2016 at 2:39 PM, Malaka Silva wrote: > Hi Biruntha, > > There can be multiple

[Architecture] Metadata for: "Identity Store Attributes" and "Attribute Profiles"; not for "Claims"

What is a claim? *A "claim" is an identifier for an underlying identity store attribute . We prefer exposing identity store attributes to the to the application level components as claims rather than direct attributes, to abstract away the implementation details of the underlying identity store.*

Re: [Architecture] Implementation of c5 multitenancy

Hi Lasantha, Shall we move what you have implemented so far to wso2 multitenancy repository [1]? Maybe we can use a new branch called 5.0.0. [1] https://github.com/wso2/carbon-multitenancy Thanks On Mon, Nov 21, 2016 at 12:53 PM, Lasantha Samarakoon wrote: > Hi all, > >