Re: [Architecture] [IoTS] Is it the right thing to package "analytics" scripts with a plugin implementation?

My take on this is slightly different. First @ a conceptual level when we say IoT Server can be extended by a plugin, we should have a clear definition of that plugin to have X, Y, Z capabilities. So I feel having analytics @ device type definition level (conceptually) is not a problem. Going by

Re: [Architecture] [WSO2 Docker Images] Creating Base Docker Images for WSO2 Products

Hi Imesh, Please find my comments inline. On Thu, Mar 24, 2016 at 10:11 AM, Imesh Gunaratne wrote: > May be you did not get the reason for doing this change properly. We are > not dropping support for Puppet or any other orchestration management > system for automating the

Re: [Architecture] [WSO2 Docker Images] Creating Base Docker Images for WSO2 Products

On Thu, Mar 24, 2016 at 9:36 AM, Chamila De Alwis wrote: > > The suggested design change covers the first approach, however if we are > dropping the Puppet support (I'm seeing Puppet based configuration of the > image only in the profile specific images), we are not going to

Re: [Architecture] Incremental Processing Support in DAS

Hi Sinthuja, Please find the comments inline. On Wed, Mar 23, 2016 at 6:50 PM, Sinthuja Ragendran wrote: > Hi Sachith, > > On Mon, Mar 21, 2016 at 5:15 PM, Sachith Withana wrote: > >> Hi all, >> >> We are adding incremental processing capability to Spark

Re: [Architecture] RFC:Security Challenges in Analytics Story

This thread described the authorization issue when reading data for gadgets ( as I mentioned in Dashboard server product council). When IoT server/ API manager publish events, it need to tell DAS whose data it is. ( however, server cannot login using that user, as then it will need to keep

Re: [Architecture] [IoTS] Is it the right thing to package "analytics" scripts with a plugin implementation?

We already have Dev Studio support for "analytics" artifacts. In this case it depends, If the plugin developer believes that he his sensor need some specialised analytics and charts then we should have the capability to provide that, this can be achieved via added the analytics in to the same

Re: [Architecture] [EMM] Android OMA-DM Standardization

+1 Thanks and Regards, Ruwan Yatawara Senior Software Engineer, WSO2 Inc. email : ruw...@wso2.com mobile : +94 77 9110413 blog : http://ruwansrants.blogspot.com/ www: :http://wso2.com On Tue, Mar 22, 2016 at 11:20 PM, Dileesha Rajapakse wrote: > Hi Ruwan, > > Yes, I

Re: [Architecture] [IoTS] Is it the right thing to package "analytics" scripts with a plugin implementation?

Hi Prabath, IoTS is basically the representation of WSO2's IoT Platform vision in the flesh (Well, not literally). The idea behind it, is to provide users with the necessary tools and components needed to get started with writing device types that will later go in actual deployments. So someone

Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload

Yes, if it is possible to put the columns names in the url as Ayoma mentioned, we must use that(First i thought it is a complex payload you want to send). Unless there are limitations, like column list doesn't exceed the url length limits, we should use GET. Thanks. On Wed, Mar 23, 2016 at 3:54

Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload

Hi, It is true that using GET request with a payload is not the best option. Even though it is not strictly prohibited in specs, it can be confusing [1]. REST architecture is very open about how we use HTTP methods, but thinking in terms of REST architecture, I do not think using POST is also the

Re: [Architecture] [REST APIs][Analytics] GET request with a payload

Hi, I think using a POST with a body, for retrieving information is fine considering the requirement. GET with body is not recommended. Thanks. On Wed, Mar 23, 2016 at 2:31 PM, Gimantha Bandara wrote: > Hi all, > > > We have a REST API in DAS to retrieve records in a

[Architecture] [REST APIs][Analytics] GET request with a payload

Hi all, We have a REST API in DAS to retrieve records in a specific table. It supports GET method with the following url format. /analytics/tables/{tableName}/{from}/{to}/{start}/{count} Sending a GET request to above url will give the records between given "from", "to" time range starting

Re: [Architecture] Incremental Processing Support in DAS

Hi Sachith, On Mon, Mar 21, 2016 at 5:15 PM, Sachith Withana wrote: > Hi all, > > We are adding incremental processing capability to Spark in DAS. > As the first stage, we added time slicing to Spark execution. > > Here's a quick introduction into that. > > *Execution*: > > In

[Architecture] [IoTS] Is it the right thing to package "analytics" scripts with a plugin implementation?

Hi Everyone, As most of you know, IoTS is a unified platform that allows users to come up with "plugins" and seamlessly add them to the framework to be able to manage different types of devices. For instance, if an organization named "Org-X" manufactures a device type "Dev-X", they can simply

Re: [Architecture] [C5] Artifact deployment coordination support for C5

Would making the deployment coordination pluggable be an option (ability to use both options) ? On Wed, Mar 23, 2016 at 2:02 PM, Srinath Perera wrote: > Kasun, I would go with JMS as it gives event persistence and you will not > loose the events even if listener is restarted.

Re: [Architecture] [C5] Artifact deployment coordination support for C5

I believe we need both here. In JMS case, we need to publish events to a topic rather than a queue. Thanks, Sameera. On Wed, Mar 23, 2016 at 2:02 PM, Srinath Perera wrote: > Kasun, I would go with JMS as it gives event persistence and you will not > loose the events even if

Re: [Architecture] [C5] Artifact deployment coordination support for C5

Kasun, I would go with JMS as it gives event persistence and you will not loose the events even if listener is restarted. --Srinath. On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe wrote: > Hi, > > Given several issues we discovered with automatic artifact synchronization

Re: [Architecture] [C5] Lifecycle listeners to listen on Artifact deployment events

On Wed, Mar 23, 2016 at 10:12 AM, KasunG Gajasinghe wrote: > > > On Wednesday, March 23, 2016, Aruna Karunarathna wrote: > >> >> >> On Tue, Mar 22, 2016 at 9:44 PM, KasunG Gajasinghe >> wrote: >> >>> Hi, >>> >>> To provide extensibility to the

[Architecture] [WSO2 Docker Images] Creating Base Docker Images for WSO2 Products

​Hi All, Recently after a discussion we had with Lakmal and the PaaS team, we reduced the size of the WSO2 Docker images by combining multiple RUN instructions, removing the puppet modules COPY command and by removing the wso2/base docker image. Afterwards we thought of redesigning the way we

Re: [Architecture] [Analytics for APIM] Integration Tests to cover Alerting scripts

Hi all, The structure is as follows, 1. You need to add a publisher ( logger) to the respective alert stream that you are testing 2. Delete the data in the respective data tables ( optional) 3. Do the publishing of simulation data ( either using a csv or programmatically. 4. Run the spark

Re: [Architecture] Service-Now Connector- Milestone plan

Hi all, I have completed the serviceNow connector. Please find the git repository, documentation and milestone plan below. [1] https://github.com/yashothara/servicenow [2] https://docs.wso2.com/display/ESBCONNECTORS/ServiceNow+Connector [3]

Re: [Architecture] [Analytics for APIM] Integration Tests to cover Alerting scripts

Sachith has implemented the basic structure. @Sachith could you please send the latest details? On Thu, Feb 25, 2016 at 11:26 AM, Srinath Perera wrote: > +1, when we have the first version, lets review!! > > --Srianth > > On Wed, Feb 24, 2016 at 5:19 PM, Sriskandarajah

Re: [Architecture] Session Affinity Alternatives

Hi Frank Agreed, IMO, we should go for session affinity model ( Option A) as default, and let him enable Option B (II) if he need. Regarding B (I) "state transfer", I think user can choose to do it ( as it does not need any help from the platform). That is zero work for us. --Srinath On Mon,