Re: [Architecture] ESB Connector for Asana

[Nirthika Rajendran]

Ok sure thank you.

On Wed, Jun 8, 2016 at 11:09 AM, Malaka Silva  wrote:

> Looks good. I'll also join.
>
> On Tue, Jun 7, 2016 at 8:23 PM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Hi Malaka,
>>
>> We had a peer review at the Jaffna office. We made the following changes
>> according to their comments.
>>
>>
>>- Change the init method to store the accesstoken in registry.
>>- Format the code according to the WSO2 standards.
>>- Add the INTEGRATION.txt file.
>>- Change the test cases for new init method.
>>
>> We are all ready, Shall we have the review on next Tuesday (14th of June)
>> at 4pm?
>>
>> Thank you
>>
>> On Tue, Jun 7, 2016 at 12:40 PM, Malaka Silva  wrote:
>>
>>> Hi Nirthika,
>>>
>>> Did we had the review? If not shall we plan for this soon.
>>>
>>> On Fri, May 27, 2016 at 10:53 AM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 Yes, we can come to the office for review next week

 Thank you.


 On Fri, May 27, 2016 at 7:54 AM, Malaka Silva  wrote:

> Hi Nirthika,
>
> Great can we have a review before publishing next week. You can come
> to our office or have it via google hangout?
>
> On Thu, May 26, 2016 at 8:20 PM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Hi Malaka,
>>
>> We have completed most of the part of asana connector including
>>
>>1. Develop the methods
>>2. Implement integration testing.
>>3. Complete documentation.
>>
>>
>> Thank you,
>> Nirthika R
>>
>> On Wed, May 4, 2016 at 7:45 AM, Malaka Silva  wrote:
>>
>>> Good progress. Keep us posted.
>>>
>>> On Wed, May 4, 2016 at 5:39 AM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 Hi Malaka,

 Yesterday we meet our mentor Kesavan to clear some problem in
 integration test. There we correct some errors and now we continue the 
 task.

 Thank you.

 On Tue, May 3, 2016 at 11:58 AM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> ok, thank you.
>
> On Tue, May 3, 2016 at 11:21 AM, Malaka Silva 
> wrote:
>
>> After finishing the integration tests should be fine.
>>
>> On Tue, May 3, 2016 at 9:18 AM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Hi Malaka,
>>>
>>> Thank you, we already have two mentors Miss. Keerthika and Mr.
>>> Kesavan. So if we have any other problem we will contact you.
>>>
>>> Can we have the hangout after finishing the integration test or
>>> it is necessary to do now?
>>>
>>> Thank you.
>>>
>>> On Mon, May 2, 2016 at 9:31 PM, Malaka Silva 
>>> wrote:
>>>
 Hi Nirthika,

 Let us know if you need any assistance to complete this?

 We can have a hangout to review the work you have done so far
 if possible?

 On Wed, Mar 9, 2016 at 4:08 PM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> Thank you Malaka,
>
> Sure we also expect that.
>
> On Wed, Mar 9, 2016 at 3:38 PM, Malaka Silva 
> wrote:
>
>> Hi Nirthika,
>>
>> Good progress. We are also planning to arrange a meetup at
>> Jaffna office in April. Feel free to come.
>>
>> On Wed, Mar 9, 2016 at 1:35 PM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Hi Malaka,
>>>
>>> Every members in my team nearly take 10 methods and do the
>>> documentation and integration test for their part also.
>>>
>>> Now we all finished about 40 methods and user documentation.
>>>
>>> This month we have final semi examination, So we plan to
>>> continue the remaining part after the exam.
>>>
>>> Thank you
>>>
>>> Regards,
>>> Nirthika Rajendran
>>>
>>>
>>> On Sun, Feb 21, 2016 at 7:24 AM, Malaka Silva <
>>> mal...@wso2.com> wrote:
>>>
 Hi Nirthika,

 ​Good progress.​


 On Sat, Feb 20, 2016 at 7:51 PM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> Thank you Malaka,
>
> Now we finished 

Re: [Architecture] ESB Connector for Asana

[Malaka Silva]

Looks good. I'll also join.

On Tue, Jun 7, 2016 at 8:23 PM, Nirthika Rajendran <
nirthika.rajend...@gmail.com> wrote:

> Hi Malaka,
>
> We had a peer review at the Jaffna office. We made the following changes
> according to their comments.
>
>
>- Change the init method to store the accesstoken in registry.
>- Format the code according to the WSO2 standards.
>- Add the INTEGRATION.txt file.
>- Change the test cases for new init method.
>
> We are all ready, Shall we have the review on next Tuesday (14th of June)
> at 4pm?
>
> Thank you
>
> On Tue, Jun 7, 2016 at 12:40 PM, Malaka Silva  wrote:
>
>> Hi Nirthika,
>>
>> Did we had the review? If not shall we plan for this soon.
>>
>> On Fri, May 27, 2016 at 10:53 AM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Yes, we can come to the office for review next week
>>>
>>> Thank you.
>>>
>>>
>>> On Fri, May 27, 2016 at 7:54 AM, Malaka Silva  wrote:
>>>
 Hi Nirthika,

 Great can we have a review before publishing next week. You can come to
 our office or have it via google hangout?

 On Thu, May 26, 2016 at 8:20 PM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> Hi Malaka,
>
> We have completed most of the part of asana connector including
>
>1. Develop the methods
>2. Implement integration testing.
>3. Complete documentation.
>
>
> Thank you,
> Nirthika R
>
> On Wed, May 4, 2016 at 7:45 AM, Malaka Silva  wrote:
>
>> Good progress. Keep us posted.
>>
>> On Wed, May 4, 2016 at 5:39 AM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Hi Malaka,
>>>
>>> Yesterday we meet our mentor Kesavan to clear some problem in
>>> integration test. There we correct some errors and now we continue the 
>>> task.
>>>
>>> Thank you.
>>>
>>> On Tue, May 3, 2016 at 11:58 AM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 ok, thank you.

 On Tue, May 3, 2016 at 11:21 AM, Malaka Silva 
 wrote:

> After finishing the integration tests should be fine.
>
> On Tue, May 3, 2016 at 9:18 AM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Hi Malaka,
>>
>> Thank you, we already have two mentors Miss. Keerthika and Mr.
>> Kesavan. So if we have any other problem we will contact you.
>>
>> Can we have the hangout after finishing the integration test or
>> it is necessary to do now?
>>
>> Thank you.
>>
>> On Mon, May 2, 2016 at 9:31 PM, Malaka Silva 
>> wrote:
>>
>>> Hi Nirthika,
>>>
>>> Let us know if you need any assistance to complete this?
>>>
>>> We can have a hangout to review the work you have done so far if
>>> possible?
>>>
>>> On Wed, Mar 9, 2016 at 4:08 PM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 Thank you Malaka,

 Sure we also expect that.

 On Wed, Mar 9, 2016 at 3:38 PM, Malaka Silva 
 wrote:

> Hi Nirthika,
>
> Good progress. We are also planning to arrange a meetup at
> Jaffna office in April. Feel free to come.
>
> On Wed, Mar 9, 2016 at 1:35 PM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Hi Malaka,
>>
>> Every members in my team nearly take 10 methods and do the
>> documentation and integration test for their part also.
>>
>> Now we all finished about 40 methods and user documentation.
>>
>> This month we have final semi examination, So we plan to
>> continue the remaining part after the exam.
>>
>> Thank you
>>
>> Regards,
>> Nirthika Rajendran
>>
>>
>> On Sun, Feb 21, 2016 at 7:24 AM, Malaka Silva <
>> mal...@wso2.com> wrote:
>>
>>> Hi Nirthika,
>>>
>>> ​Good progress.​
>>>
>>>
>>> On Sat, Feb 20, 2016 at 7:51 PM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 Thank you Malaka,

 Now we finished nearly 35 Methods, and going to develop
 documentation.
 We contact some staff from Jaffna branch as our mentors
 (Ms. M. Keerthika). They also help us

 I will put 

Re: [Architecture] [IS] Support for Google reCaptha

[Thanuja Jayasinghe]

@Omindu

We have generated the key pair providing 'localhost' as the domain name and
we are going to ship this key pair OOTB with the default pack. So any user
can use this key pair for testing.
If they want to configure it for different domain name, they have to
generate a new key pair for that domain.

@Harsha

reCaptcha requires internet connection, since the user validation depend on
communication between Google.

But we will make the filter more generic, so that we can add CAPTCHA as a
connector.

Thanks,

On Wed, Jun 8, 2016 at 1:44 AM, Harsha Thirimanna  wrote:

> Any plan to support *CAPTCHA *in IS without having internet connection ?
> Because previous version of *CAPTCHA* is OOB service and now we are going
> to use google service. Do we have way to install google service plugin or
> something in offline  within product ?
>
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * *
> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ *
> *harshathirimannlinked-in: **http:
> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> *
>
> *Lean . Enterprise . Middleware*
>
>
> On Wed, Jun 8, 2016 at 1:38 AM, Omindu Rathnaweera 
> wrote:
>
>> First we need to register at [2] and create an API key pair for the
>>> required domain.
>>
>>
>> Should a product user generate their own key pair and configure the
>> product prior to using reCaptcha ?
>>
>> Regards,
>> Omindu.
>>
>>
>> On Tue, Jun 7, 2016 at 11:33 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> *Why reCaptcha?*
>>>
>>> *"reCAPTCHA is a free service that protects your website from spam and
>>> abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
>>> CAPTCHAs to keep automated software from engaging in abusive activities on
>>> your site. It does this while letting your valid users pass through with
>>> ease." -Google[1]*
>>>
>>>
>>> *How does reCaptcha works?*
>>>
>>> First we need to register at [2] and create an API key pair for the
>>> required domain.  The key pair consists of a site key and secret. The site
>>> key used when we display reCaptcha widget on a page. After verification,
>>> new parameter called 'g-recaptcha-response' will be available in the
>>> form which user submits. From the server side we can verify that reCaptcha
>>> response calling the Google API with the secret key.
>>>
>>>
>>> *Where we're going to use reCaptcha?*
>>>
>>> Basically any place which can be vulnerable to Bots attack,
>>>
>>>1. SSO login flow
>>>2. User recovery flows
>>>3. User registration flow
>>>
>>>
>>> *Implementation*
>>>
>>> Conditions to enable reCaptcha is different from one scenario to
>>> another. As an example user registration may enable reCaptcha by default,
>>> but SSO login page may enable it after n failed attempts from a single
>>> user. Also reCaptcha requirements may be different from one tenant to
>>> another.
>>>
>>> So we have introduced filter called "ReCaptchaFilter" to intercept
>>> requests and pass them to a reCaptcha connector which can handle a
>>> particular scenario. Connector will provide following information to the
>>> filter,
>>>
>>>- Whether the connector can handle the request
>>>- Priority of the connector
>>>- Whether the reCapatha verification is needed for the current
>>>request
>>>- Whether that attempt is a successful or not
>>>
>>> Based on above information filter will select a connector which can
>>> handle the incoming request and will validate reCaptcha if needed.
>>>
>>> Also to keep this in a state less manner, IS will do following,
>>>
>>>- Will evaluate the need for reCaptcha at the server side
>>>- Will inform and provide necessary data to the pages if server is
>>>expecting reCaptha validation
>>>
>>>
>>> *OOTB Connectors*
>>>
>>> IS will provide two reCpatcha connectors OOTB as "
>>> SSOLoginReCaptchaConnector" and "PathBasedReCaptchaConnector", which
>>> implement "ReCaptchaConnector" interface. These connectors also
>>> implement "IdentityGovernanceConnector" to enable UI based
>>> configuration management.
>>>
>>> SSOLoginReCaptchaConnector - Can enable reCaptcha after n number of
>>> failed attempts form a single user. This connector does not depend on the
>>> user agent and will take the sum of failed attempts from any agent.
>>> PathBasedReCaptchaConnector - Can validate reCaptcha for a request
>>> path. This will always validate reCaptcha for a given request path.
>>>
>>>
>>> Appreciate your input.
>>>
>>> [1] - https://developers.google.com/recaptcha/intro
>>> [2] - https://www.google.com/recaptcha/admin
>>>
>>> Thanks,
>>> Thanuja
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. 

Re: [Architecture] [IS] Supporting user information recovery scenarios in IS user portal

[Malithi Edirisinghe]

Hi All,

I have following concern with regard to moving the account recovery web
application from OOTB supported KAPTCHA to google reCaptcha.

As noted at [1], we should have an API key pair. Thus, we will not be able
to enable this for the webapp by default (with the fresh IS server pack).
Further, previously, captcha validation is a must for recovery API calls(
Ex: Password Recovery).
So does the new implementation enforce that verification?
If it does, we would also not be able to view those recovery options by
default.

@Isura,
Could you please initiate a thread on the design of the new Identity
Management APIs

[1][Architecture] [IS] Support for Google reCapth

Thanks,
Malithi.

On Tue, Jun 7, 2016 at 11:33 AM, Thanuja Jayasinghe 
wrote:

> Hi Omindu,
>
> Yes. We can't use reCaptcha without internet. But the chance of having
> Bots attack from a internal network is very less. So we can either disable
> reCaptcha when server is not connect to the internet or have the old
> captcha implementation.
>
> +1 for keep the existing captcha implementation. But we have to modify
> login, self-registration and recovery flows to add captcha/reCaptcha in a
> pluggable manner.
>
> Thanks,
> Thanuja.
>
> On Tue, Jun 7, 2016 at 11:14 AM, Isura Karunaratne  wrote:
>
>> Hi,
>>
>> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Since reCaptcha requires to call Google's services for captcha
>>> generation and validation, we won't be able to use the dashboard with
>>> captcha when we are running IS in an environment without internet
>>> connectivity. I'm assuming we are not shipping the old captcha
>>> implementation in 5.3.0 so a user will not be able to switch to an
>>> internally managed captcha implementation with a simple config change.
>>>
>>> It'll be good if we can make the old captcha implementation (or a
>>> similar implementation) available (by means of an extension or a sample
>>> maybe ?) so a user can switch to an internally managed captcha model
>>> without much work. WDYT ?
>>>
>>
>> +1. but, we better to decouple old captcha implementation with recovery
>> flows.
>>
>> Thanks
>> Isura
>>
>>
>>> Regards,
>>> Omindu.
>>>
>>> On Sun, Jun 5, 2016 at 12:35 PM, Malithi Edirisinghe 
>>> wrote:
>>>
 Hi Isura,

 Noted.

 I've got one more concern.
 Initially, as you may have noted in the top most mail, recovery
 scenarios were to be supported in the login page of the end user
 dashboard in IS. But in a consecutive discussion it was highlighted that
 these options should be provided in the default SSO login page. Thus, upon
 a successful recovery or registration, the flow should be as below.

1. End user will be redirected to the login page.
2. End user will enter the credentials
3. End user is authenticated and upon successful authentication
user will be redirected to the Service Provider application (Ex: ACS 
 url of
the SP).

 So at the moment, we are using the param 'sessionDataKey' to map the
 server session across modules, which can be used even here to retrieve the
 respective Service Provider who initiated the flow. But, when it comes to
 recovery with notifications there is no parameter being communicated to
 identify the respective Service Provider. Can we please address this also,
 along with this effort ?

 Thanks,
 Malithi.

 On Sun, Jun 5, 2016 at 8:39 AM, Isura Karunaratne 
 wrote:

> Hi Malithi,
>
> These steps seem to be ok. However we are going to move from KAPCHA to
> google reCaptcha in IS 5.3.0 and this captcha implementation is decoupled
> with each flow you mentioned. So, in new implementation captcha validation
> will happen before invoking to the backend APIs.
>
> In "security questions based password recovery flow", we are going to
> add a new parameter to parameterize the minimum number of questions that
> user should be answered to recover the password. In the previous releases
> (IS 5, IS5.1.0) this is an application side configuration and it was not a
> server side configuration. With IS 5.3.0 onwards tenant admin can define
> the minimum number of questions that user should be answered to recover 
> the
> password.
>
> Thanks
> Isura
>
>
>
> On Fri, Apr 29, 2016 at 11:40 AM, Malithi Edirisinghe <
> malit...@wso2.com> wrote:
>
>> Hi All,
>>
>> We are working on $subject.
>>
>> So with this, we will be supporting below options in the login page
>> of the end user dashboard in IS.
>>
>>1. Forgot Password (Password Recovery)
>>2. Forgot Username (Username Recovery)
>>3. Create an account (Self Signup)
>>
>> Below I have listed the user stories that we identified, to 

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Dakshika Jayathilaka]

Hi All,

Ideally, we need to provide an option to re-edit once they generated. AFAIK
we don't have that option yet.

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Tue, Jun 7, 2016 at 11:34 PM, Manuranga Perera  wrote:

> How would a user modify or regenerate with slight change?
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [CEP] Extending the Regression Function to support time window

[Charini Nanayakkara]

Hi Seshika.

Noted with thanks. In that case what name would you suggest for these new
extensions (i.e. new regression, outlier and forecast functions)

Regards,
Charini

On Tue, Jun 7, 2016 at 7:13 PM, Seshika Fernando  wrote:

> No, the existing regression function should remain, as its a different
> usecase. There are many instances where we need to perform regression on a
> set of events that are not limited by a time duration. In that case, the
> existing regression implementation will be used. However, the duration
> parameter should be available for outlier and forecast extensions as well.
> So a user should be able to use the outlier/forecast regression functions
> with/without duration parameter. So your new version should be applicable
> to all 3 regression extensions (linear regression, outlier, forecast).
>
> seshi
>
> On Tue, Jun 7, 2016 at 6:32 PM, Charini Nanayakkara 
> wrote:
>
>> Hi Seshika, Suho,
>>
>> Is the existent regression function to be entirely replaced by the new
>> one? If so it's necessary to change implementation of outlier and forecast
>> extensions as well, since those are based on the regression implementation.
>> Furthermore, there's the concern of existent applications being rendered
>> useless if the old version is entirely removed. If it's preferred to keep
>> both, a new name is required for this extension.  Since the regression
>> function supports both time and length, a name such as regressTimeLength
>> would be appropriate IMO. Please give your suggestions.
>>
>> Regards,
>> Charini
>>
>> On Sun, Jun 5, 2016 at 11:28 AM, Seshika Fernando 
>> wrote:
>>
>>> Hi,
>>> The length ceiling is necessary along with the duration parameter. The
>>> reason the batch size was originally implemented was to optimize
>>> performance when large datasets are considered for regression. We need to
>>> be able to give an upper bound. So for example in this case, if user uses a
>>> large duration (24 hours)and there are millions of events, then if we put a
>>> batch size of 1 million it will consider the last 1 million events in the
>>> last 24 hours. Which is a valid use case.
>>>
>>> For this reason, the ability to specify both duration and batch size is
>>> important.
>>>
>>> Seshi
>>> On 2 Jun 2016 14:45, "Charini Nanayakkara"  wrote:
>>>
 Noted with thanks. Will proceed with the implementation likewise.

 Charini

 On Thu, Jun 2, 2016 at 2:28 PM, Sriskandarajah Suhothayan <
 s...@wso2.com> wrote:

> I think having batchSize & duration will be good as this will limit
> the number of events considered, this can help to improve performance as
> well.
>
> Suho
>
> On Thu, Jun 2, 2016 at 1:59 PM, Charini Nanayakkara  > wrote:
>
>> Hi Tishan,
>>
>> For my requirement, having time window alone is adequate. So your
>> point might be valid. However I'm concerned of the re-usability of the
>> extension.
>>
>> @Srinath, WDYT? Which would be the better option? Having a single
>> implementation or two different ones?
>>
>> Thanks
>>
>> On Thu, Jun 2, 2016 at 1:48 PM, Tishan Dahanayakage 
>> wrote:
>>
>>> Charini,
>>>
>>> My knowledge on the on this domain is sparse. Hence I do not know
>>> whether a scenario where time AND length is a valid business case. If 
>>> it is
>>> a valid business case +1 for the design including both parameters in 
>>> same
>>> implementation.
>>>
>>> Thanks
>>> /Tishan
>>>
>>> On Thu, Jun 2, 2016 at 12:54 PM, Charini Nanayakkara <
>>> chari...@wso2.com> wrote:
>>>
 Hi Tishan,

 Yes. Assuming batch size is 5 and time window is 20 mins, only 5
 out of 10 events which arrive within last 5 mins would be processed 
 due to
 batch size constraint (even though all events must be processed if time
 alone was considered). Having separate implementations would work on 
 the
 majority of the scenarios, since only time OR length is usually 
 applicable
 but not both. However, having two implementations would cause trouble 
 in
 the situations where both the time factor and length are important
 (equivalent to AND operation on the two constraints). If our 
 requirement is
 to have only one of the two constraints, we can use a very large value 
 for
 the other parameter (i.e. if we only need to limit number of events 
 based
 on time = 1 sec constraint, we can specify 1,000,000 for batch size
 assuming we have prior knowledge that 1,000,000 events would never 
 arrive
 within 1 sec). IMHO neither of the two options (separate or single
 implementation) are perfect for every scenario. However having a single

Re: [Architecture] Dep sync strategies for Carbon 4 products in Kubernetes

[Chamila De Alwis]

Hi Imesh,


On Wed, Jun 8, 2016 at 5:32 AM, Imesh Gunaratne  wrote:

> ​It would be better if we can implement this feature without tightly
> coupling with the K8S API.​ Therefore I prefer the pull based model than
> this.
>

I agree. This would require different ways of contacting any platform
specific name resolution service to get the list of target containers.


>
>
>> The pull method works the other way, i.e. initiated by the GW worker
>> nodes and has to be run continuously on a loop.
>>
>
> ​This approach can be applied to API-M on any container cluster manager
> (and also on VMs) with very few changes. AFAIU it's matter of changing how
> SSH server and rsync command processes are run on each GW node. K8S can use
> separate containers for these using pods and Mesos can use supervisord [4].
>

I think supervisord would be applicable to any Docker based platform, be it
Kubernetes or Mesos. Is there an additional advantage in going for a
separate container to run sshd with a shared volume?

One complication we'll come across (regardless of whether rsync pull or
push) that I couldn't further elaborate was the artifact synchronization
*between* GW Manager nodes when manager is in HA. This is when there are
multiple GW Manager nodes, fronted with a load balancer. There will be only
one active pod at a given time, and the request will be directed to the
next available pod when the former goes down.

For this, if we use a hostPath approach to share data, we'll also need to
specify a node affinity to limit the node that the pod is spawned on. This
way we can make sure the same location is mounted to every pod. The other
option is to use something like Flocker with a Block storage service,
however IMO it is a too complex method to approach a simple problem.




Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dep sync strategies for Carbon 4 products in Kubernetes

[Imesh Gunaratne]

Hi Chamila,

Thanks for looking into this. Please find my comments inline:

On Tue, Jun 7, 2016 at 6:03 AM, Chamila De Alwis  wrote:
>
>
> In the push method, it's the GW manager that initiates the process.
>
>1. Add a folder watcher (inotifywatch[1]) to
>repository/deployment/server/synapse-configs
>2. When triggered
>   1. Contact Kubernetes API and get list of WORKER_SVC container IPs
>   2. for each container IP, Rsync with --delete
>
> ​It would be better if we can implement this feature without tightly
coupling with the K8S API.​ Therefore I prefer the pull based model than
this.


> The pull method works the other way, i.e. initiated by the GW worker nodes
> and has to be run continuously on a loop.
>

​This approach can be applied to API-M on any container cluster manager
(and also on VMs) with very few changes. AFAIU it's matter of changing how
SSH server and rsync command processes are run on each GW node. K8S can use
separate containers for these using pods and Mesos can use supervisord [4].

[4] https://docs.docker.com/engine/admin/using_supervisord/

Thanks


> Additionally, Kubernetes supports a volume plugin named Git Volume [2],
> which is basically an emptyDir volume with an initial "git clone" command
> done on the provided remote repository.
>
> The issue with this is that there is no push functionality when the
> contents are updated. This might be solved by extending the Git Repo volume
> plugin and writing a Carbon Volume Plugin for Kubernetes, however IMO it
> would come up with the same set of problems we have in the current SVN
> based deployment synchronization, only with an additional code base.
>
> NFS volume based approach was also considered, however because of the
> limitations in moving the mount between the nodes (solutions like Flocker
> works on Block Level storage [3]), and managing read-write capability of
> multiple containers it also seems to be a complex path.
>
> IMO out of these approaches, Rsync is the possible candidate (specifically
> the push method), although it takes a few workarounds to achieve
> functionality. GW Managers would need to synchronize artifacts between
> themselves, as well as towards the worker nodes, and the push job should
> only run from the active manager node.
>
> I highly appreciate any input on this.
>
> [1] - http://linux.die.net/man/1/inotifywatch
> [2] - http://kubernetes.io/docs/user-guide/volumes/#gitrepo
> [3] -
> https://docs.clusterhq.com/en/latest/faq/#can-i-attach-a-single-volume-to-multiple-hosts
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>


-- 
*Imesh Gunaratne*
Software Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Regenerating client secret/key and revoking an oauth app in OAuth 2.0 implementation

[Harsha Thirimanna]

On Mon, Jun 6, 2016 at 1:33 AM, Prabath Siriwardana 
wrote:

> Yes.. We need to have it...


Created a public JIRA to track this
https://wso2.org/jira/browse/IDENTITY-4666​
​

> Since we are now talking about client id and client secret - can we also
> make the app authentication generic - or in other words a given app should
> be able to use the authentication option of its choice. We can still use
> client id as the app identifier...
>
> Thanks!
>
>
> On Sunday, June 5, 2016, Harsha Thirimanna  wrote:
>
>> Hi Prabath/Johan,
>> Do we allow to set an expiration time to this client secret ? Because as
>> in the DCR spec [1], for the response it is required attribute '
>> client_secret_expires_at' and we set it as 0 because of it will never
>> expired.
>>
>> [1]
>> https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse
>>
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead; WSO2, Inc.; http://wso2.com
>> * *
>> *email: **hars...@wso2.com** cell: +94 71 5186770 *
>> *twitter: **http://twitter.com/ *
>> *harshathirimannlinked-in: **http:
>> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>>
>> On Fri, Jun 3, 2016 at 5:46 PM, Prabath Siriwardana 
>> wrote:
>>
>>>
>>>
>>> On Thu, Jun 2, 2016 at 10:30 PM, Indunil Upeksha Rathnayake <
>>> indu...@wso2.com> wrote:
>>>
 Hi,
 I am working on implementing regeneration of client secret/key of an
 oauth app and revocation of an oauth app for the next milestone release of
 Identity Server. Appreciate your feedbacks on the following approaches I
 have taken.

 A trusted client would need to update the client secret/key, in order
 to prevent the abuse of revealed client secret/key. So for addressing that,
 I am working on adding two options as *Regenerate Client Secret *and 
 *Regenerate
 Consumer Key* for oauth applications in IS. After a client secret/key
 get regenerated, that will immediately invalidate any active authorization
 code, access token or refresh token, issued to the respective client.

 *Will it be necessary to add two options for revoking client secret and
 key or better to go for a different approach?*

>>>
>>> I guess (as discussed in this thread already) - having the ability to
>>> change the consumer secret would be enough. Changing the consumer key is
>>> bit challanging too - we would have all the analytics data against the
>>> consumer key.
>>>
>>> Also - consumer key is not something - someone would remember and use -
>>> so I don't think its same as the username - so I don't see any need to
>>> change it.
>>>
>>>



 And apart from that planning for the implementation of *Revoking an
 oauth app*. In there the oauth app will be revoked and that also will
 immediately invalidate any active authorization code, access token or
 refresh token, issued to the respective client. In order to activate the
 oauth app again, need to regenerate the client secret.


 *In there to activate the app, better to regenerate "both client key
 and secret" or "either client key or secret"?*

>>>
>>> Revoking an app means - mostly the revoking of its consumer secret (the
>>> previous scenario).
>>>
>>> Another couple of use cases we can address with this:
>>>
>>> 1. Blocking an app temporary - Deactivate the App - and the Activate it
>>> after sometime - nothing to do with the consumer secret revocation.
>>>
>>> 2. Ability to revoke an access token (s) issued on behalf of a user for
>>> a particular app.
>>>
>>> 3. Ability to revoke all the access tokens issued on behalf of a user
>>> across all the apps.
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>


 Really value your ideas/suggestions on improving this feature.

 Thanks and Regards
 --
 Indunil Upeksha Rathnayake
 Software Engineer | WSO2 Inc
 Emailindu...@wso2.com


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Twitter : @prabath
>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>
>>> Mobile : +1 650 625 7950
>>>
>>> http://facilelogin.com
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://facilelogin.com
>
>
___
Architecture 

Re: [Architecture] [IS] Support for Google reCaptha

[Harsha Thirimanna]

Any plan to support *CAPTCHA *in IS without having internet connection ?
Because previous version of *CAPTCHA* is OOB service and now we are going
to use google service. Do we have way to install google service plugin or
something in offline  within product ?


*Harsha Thirimanna*
Associate Tech Lead; WSO2, Inc.; http://wso2.com
* *
*email: **hars...@wso2.com* * cell: +94 71 5186770 *
*twitter: **http://twitter.com/ *
*harshathirimannlinked-in: **http:
**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
*

*Lean . Enterprise . Middleware*


On Wed, Jun 8, 2016 at 1:38 AM, Omindu Rathnaweera  wrote:

> First we need to register at [2] and create an API key pair for the
>> required domain.
>
>
> Should a product user generate their own key pair and configure the
> product prior to using reCaptcha ?
>
> Regards,
> Omindu.
>
>
> On Tue, Jun 7, 2016 at 11:33 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> *Why reCaptcha?*
>>
>> *"reCAPTCHA is a free service that protects your website from spam and
>> abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
>> CAPTCHAs to keep automated software from engaging in abusive activities on
>> your site. It does this while letting your valid users pass through with
>> ease." -Google[1]*
>>
>>
>> *How does reCaptcha works?*
>>
>> First we need to register at [2] and create an API key pair for the
>> required domain.  The key pair consists of a site key and secret. The site
>> key used when we display reCaptcha widget on a page. After verification,
>> new parameter called 'g-recaptcha-response' will be available in the
>> form which user submits. From the server side we can verify that reCaptcha
>> response calling the Google API with the secret key.
>>
>>
>> *Where we're going to use reCaptcha?*
>>
>> Basically any place which can be vulnerable to Bots attack,
>>
>>1. SSO login flow
>>2. User recovery flows
>>3. User registration flow
>>
>>
>> *Implementation*
>>
>> Conditions to enable reCaptcha is different from one scenario to another.
>> As an example user registration may enable reCaptcha by default, but SSO
>> login page may enable it after n failed attempts from a single user. Also
>> reCaptcha requirements may be different from one tenant to another.
>>
>> So we have introduced filter called "ReCaptchaFilter" to intercept
>> requests and pass them to a reCaptcha connector which can handle a
>> particular scenario. Connector will provide following information to the
>> filter,
>>
>>- Whether the connector can handle the request
>>- Priority of the connector
>>- Whether the reCapatha verification is needed for the current request
>>- Whether that attempt is a successful or not
>>
>> Based on above information filter will select a connector which can
>> handle the incoming request and will validate reCaptcha if needed.
>>
>> Also to keep this in a state less manner, IS will do following,
>>
>>- Will evaluate the need for reCaptcha at the server side
>>- Will inform and provide necessary data to the pages if server is
>>expecting reCaptha validation
>>
>>
>> *OOTB Connectors*
>>
>> IS will provide two reCpatcha connectors OOTB as "
>> SSOLoginReCaptchaConnector" and "PathBasedReCaptchaConnector", which
>> implement "ReCaptchaConnector" interface. These connectors also
>> implement "IdentityGovernanceConnector" to enable UI based configuration
>> management.
>>
>> SSOLoginReCaptchaConnector - Can enable reCaptcha after n number of
>> failed attempts form a single user. This connector does not depend on the
>> user agent and will take the sum of failed attempts from any agent.
>> PathBasedReCaptchaConnector - Can validate reCaptcha for a request path.
>> This will always validate reCaptcha for a given request path.
>>
>>
>> Appreciate your input.
>>
>> [1] - https://developers.google.com/recaptcha/intro
>> [2] - https://www.google.com/recaptcha/admin
>>
>> Thanks,
>> Thanuja
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Support for Google reCaptha

[Omindu Rathnaweera]

>
> First we need to register at [2] and create an API key pair for the
> required domain.


Should a product user generate their own key pair and configure the product
prior to using reCaptcha ?

Regards,
Omindu.


On Tue, Jun 7, 2016 at 11:33 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> *Why reCaptcha?*
>
> *"reCAPTCHA is a free service that protects your website from spam and
> abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
> CAPTCHAs to keep automated software from engaging in abusive activities on
> your site. It does this while letting your valid users pass through with
> ease." -Google[1]*
>
>
> *How does reCaptcha works?*
>
> First we need to register at [2] and create an API key pair for the
> required domain.  The key pair consists of a site key and secret. The site
> key used when we display reCaptcha widget on a page. After verification,
> new parameter called 'g-recaptcha-response' will be available in the form
> which user submits. From the server side we can verify that reCaptcha
> response calling the Google API with the secret key.
>
>
> *Where we're going to use reCaptcha?*
>
> Basically any place which can be vulnerable to Bots attack,
>
>1. SSO login flow
>2. User recovery flows
>3. User registration flow
>
>
> *Implementation*
>
> Conditions to enable reCaptcha is different from one scenario to another.
> As an example user registration may enable reCaptcha by default, but SSO
> login page may enable it after n failed attempts from a single user. Also
> reCaptcha requirements may be different from one tenant to another.
>
> So we have introduced filter called "ReCaptchaFilter" to intercept
> requests and pass them to a reCaptcha connector which can handle a
> particular scenario. Connector will provide following information to the
> filter,
>
>- Whether the connector can handle the request
>- Priority of the connector
>- Whether the reCapatha verification is needed for the current request
>- Whether that attempt is a successful or not
>
> Based on above information filter will select a connector which can handle
> the incoming request and will validate reCaptcha if needed.
>
> Also to keep this in a state less manner, IS will do following,
>
>- Will evaluate the need for reCaptcha at the server side
>- Will inform and provide necessary data to the pages if server is
>expecting reCaptha validation
>
>
> *OOTB Connectors*
>
> IS will provide two reCpatcha connectors OOTB as "
> SSOLoginReCaptchaConnector" and "PathBasedReCaptchaConnector", which
> implement "ReCaptchaConnector" interface. These connectors also implement
> "IdentityGovernanceConnector" to enable UI based configuration management.
>
> SSOLoginReCaptchaConnector - Can enable reCaptcha after n number of
> failed attempts form a single user. This connector does not depend on the
> user agent and will take the sum of failed attempts from any agent.
> PathBasedReCaptchaConnector - Can validate reCaptcha for a request path.
> This will always validate reCaptcha for a given request path.
>
>
> Appreciate your input.
>
> [1] - https://developers.google.com/recaptcha/intro
> [2] - https://www.google.com/recaptcha/admin
>
> Thanks,
> Thanuja
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Omindu Rathnaweera
Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

How would a user modify or regenerate with slight change?
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS] Support for Google reCaptha

[Thanuja Jayasinghe]

Hi All,

I'm working on $subject.

*Why reCaptcha?*

*"reCAPTCHA is a free service that protects your website from spam and
abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
CAPTCHAs to keep automated software from engaging in abusive activities on
your site. It does this while letting your valid users pass through with
ease." -Google[1]*


*How does reCaptcha works?*

First we need to register at [2] and create an API key pair for the
required domain.  The key pair consists of a site key and secret. The site
key used when we display reCaptcha widget on a page. After verification,
new parameter called 'g-recaptcha-response' will be available in the form
which user submits. From the server side we can verify that reCaptcha
response calling the Google API with the secret key.


*Where we're going to use reCaptcha?*

Basically any place which can be vulnerable to Bots attack,

   1. SSO login flow
   2. User recovery flows
   3. User registration flow


*Implementation*

Conditions to enable reCaptcha is different from one scenario to another.
As an example user registration may enable reCaptcha by default, but SSO
login page may enable it after n failed attempts from a single user. Also
reCaptcha requirements may be different from one tenant to another.

So we have introduced filter called "ReCaptchaFilter" to intercept requests
and pass them to a reCaptcha connector which can handle a particular
scenario. Connector will provide following information to the filter,

   - Whether the connector can handle the request
   - Priority of the connector
   - Whether the reCapatha verification is needed for the current request
   - Whether that attempt is a successful or not

Based on above information filter will select a connector which can handle
the incoming request and will validate reCaptcha if needed.

Also to keep this in a state less manner, IS will do following,

   - Will evaluate the need for reCaptcha at the server side
   - Will inform and provide necessary data to the pages if server is
   expecting reCaptha validation


*OOTB Connectors*

IS will provide two reCpatcha connectors OOTB as "SSOLoginReCaptchaConnector"
and "PathBasedReCaptchaConnector", which implement "ReCaptchaConnector"
interface. These connectors also implement "IdentityGovernanceConnector" to
enable UI based configuration management.

SSOLoginReCaptchaConnector - Can enable reCaptcha after n number of failed
attempts form a single user. This connector does not depend on the user
agent and will take the sum of failed attempts from any agent.
PathBasedReCaptchaConnector - Can validate reCaptcha for a request path.
This will always validate reCaptcha for a given request path.


Appreciate your input.

[1] - https://developers.google.com/recaptcha/intro
[2] - https://www.google.com/recaptcha/admin

Thanks,
Thanuja
-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Manu,

On Tue, Jun 7, 2016 at 8:05 PM, Manuranga Perera  wrote:

> Hi Tanya,
>
> 1) Are we really generating gadgets, though the wizard or generating
> JSONs? (I personally don't like the former, as we have discussed before)
>
We are generating the gadget not JSONs.

>
> 2) If we are generating, which files are dynamic generated Vs. which files
> are copies? I think it should be possible to figure out by looking at files.
>
You can find the template that we use now at [1]. Rest of the files will be
directly copied from the chart or provider template.

[1]
https://github.com/wso2/carbon-dashboards/tree/master/apps/portal/templates/gadgets/gadget-generation-templates


Thanks,
Tanya

>
> On Tue, Jun 7, 2016 at 5:41 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
>> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
>> Appreciate your input.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Archiecture] ESB - Feature Request - JMS transactions with non-blocking transports

[Isuru Udana]

Hi Manu,

+1. Good idea.
I also think it is doable in the way you suggested, however we need to
investigate little bit more on this.







On Tue, Jun 7, 2016 at 10:00 PM, Manuranga Perera  wrote:

> AFAIK, correct me if I am wrong, the transaction is closed when the thread
> returns [1].This means we can't use call mediator (or send) with JMS proxy
> with transactions.
>
> If we keep JMS session/context in the message context and only close after
> the mediation flow is over, we will be able to handle more concurrent JMS
> requests. WDUT?
>
> [1] https://docs.wso2.com/display/ESB460/JMS+Transactions
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>



-- 
*Isuru Udana*
Technical Lead
WSO2 Inc.; http://wso2.com
email: isu...@wso2.com cell: +94 77 3791887
blog: http://mytecheye.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Archiecture] ESB - Feature Request - JMS transactions with non-blocking transports

[Manuranga Perera]

AFAIK, correct me if I am wrong, the transaction is closed when the thread
returns [1].This means we can't use call mediator (or send) with JMS proxy
with transactions.

If we keep JMS session/context in the message context and only close after
the mediation flow is over, we will be able to handle more concurrent JMS
requests. WDUT?

[1] https://docs.wso2.com/display/ESB460/JMS+Transactions

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

I refer to the states defined in the HumanTask spec:
http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-06.pdf
Section 4.10 defines these states - "claimed" is not what the standard
defines because different implementations had slightly different semantics,
thus, we renamed the states and defined their operational semantics...


Best regards,
Frank

2016-06-06 17:55 GMT+02:00 Manuranga Perera :

> There is no such status like "In progress".
>
> Isn't "claiming" a task is equivalent to making "in progress".
>
> In your example of call, I'll first claim and then start the call.
>
> On Mon, Jun 6, 2016 at 11:51 AM, Manuranga Perera  wrote:
>
>> I think as much as possible we have to achieve this with Event-driven
>>> architecture rather than schedulers.
>>>
>> +1
>>
>>> So we can use simple cache mechanism as below
>>
>> While this is possible, I don't see why we are trying to shave off a few
>> milliseconds from the task creation and make the it more complex even
>> sacrificing correctness. Isn't this some premature optimization ?
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Manuranga Perera]

>
> If we want to model with the permissions then we should be able to add the
> permissions dynamically, but this is not possible with current carbon -
> 4.x. And as I have mentioned above, this cannot be included in the global
> level as well, because having a settings or delete privileges for dashboard
> - X, doesn't mean you have the same privileges for dashboard - Y. And hence
> we thought of going with roles approach for this one as well. I agree, the
> role names for settings and delete is bit odd, we need to come up with
> proper names for those. :)
>

I think it is possible to dynamically create any permissions via the API
even in C4

2) Does "settings" make sense, because if you are an editor, anyway you'll
>> have full access to the JSON, don't you?
>
> In settings you have the full privileges, ie, you can even remove the user
> who initially created the dashboard, IMHO it provides the full control of
> the dashboard. Designer doesn't have such privileges, he/she can only
> add/remove gadgets, pages etc which is related to designing the dashboard.
> Therefore we need to have a different role to control the access of the
> settings page.


We may call this "Owners"?

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Sinthuja Ragendran]

Hi Manu,

On Tue, Jun 7, 2016 at 3:24 PM, Manuranga Perera  wrote:

> Following names make sense as roles:
>
>- internal/dashboard/{dashboardID}/editor
>- internal/dashboard/{dashboardID}/viewer
>
> but
>
>- internal/dashboard/{dashboardID}/settings
>- internal/dashboard/{dashboardID}/delete
>
> Sounds a bit weird for role names. As Suho said, it can be modeled as
> permissions as well.
>

If we want to model with the permissions then we should be able to add the
permissions dynamically, but this is not possible with current carbon -
4.x. And as I have mentioned above, this cannot be included in the global
level as well, because having a settings or delete privileges for dashboard
- X, doesn't mean you have the same privileges for dashboard - Y. And hence
we thought of going with roles approach for this one as well. I agree, the
role names for settings and delete is bit odd, we need to come up with
proper names for those. :)


>
> 1) Do you intend to add people to each via DS UI? (In that case roles
> might be easier)
>

The dashboard creator will be automatically assigned to all of the above
mentioned roles. If he/she want to share with some additional group/role,
he/she can add to the allowed roles list. In the case that if he/she wants
to share only with some users, they needs to be added to management UI. But
I agree, to have the proper flow we need to have UI in DS side for this.

2) Does "settings" make sense, because if you are an editor, anyway you'll
> have full access to the JSON, don't you?
>

In settings you have the full privileges, ie, you can even remove the user
who initially created the dashboard, IMHO it provides the full control of
the dashboard. Designer doesn't have such privileges, he/she can only
add/remove gadgets, pages etc which is related to designing the dashboard.
Therefore we need to have a different role to control the access of the
settings page.

Thanks,
Sinthuja.


> On Tue, Jun 7, 2016 at 7:59 AM, Sinthuja Ragendran 
> wrote:
>
>> According to the chat I had with Johann, we have came up with this model.
>> Basically as per now in C4 we don't have a way to add a permission
>> dynamically, and similar requirement has been raised in IS as well and they
>> have come up with this model.
>>
>> The main reason for this is, there might be some dashboard that you are
>> working on and want to share between some users and grant some privileges.
>> It's not doable with global permission, bcz having an edit permission for
>> say sales dashboard doesn't mean you have the permission for admin
>> dashboard. Therefore this needs to be controlled per dashboard, not
>> globally.
>>
>> Thanks,
>> Sinthuja.
>>
>> On Tue, Jun 7, 2016 at 11:12 AM, Sriskandarajah Suhothayan > > wrote:
>>
>>> Why are we not using different permissions for each dashboard than using
>>>  roles. I believe using permissions will be more scalable than using roles.
>>> WDYT?
>>>
>>> Regards
>>> Suho
>>>
>>> On Tue, Jun 7, 2016 at 2:38 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi Udara,

 Since these are internal roles, they are not stored in LDAP. So it will
 work fine.

 Thanks,
 Nisala

 On Tue, Jun 7, 2016 at 10:57 AM, Udara Rathnayake 
 wrote:

> Another question, ​Is this going to work if we have to connect to a
> read-only LDAP/A
> ​D​
> userstore?
>
> On Tue, Jun 7, 2016 at 9:43 AM, Tanya Madurapperuma 
> wrote:
>
>> Is this model scalable? Because per dashboard we will have to create
>> 4 internal roles. So if we have N number of dashboards we will end up
>> having 4 * N number of internal roles.
>>
>> @ IS team : is this approach fine? Or is there any better approach?
>>
>> Thanks,
>> Tanya
>>
>> On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> adding Johan and Manuranga
>>>
>>> Thanks,
>>> Nisala
>>>
>>> On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi all,

 I am working on implementing an access levels model for WSO2
 Dashboard Server. Currently global permission model for 
 create/delete/login
 is implemented by Megala. Since it does not support to provide per
 dashboard level access for the users. I am going to extend it and 
 implement
 a permission model that can be used to provide per dashboard level 
 access
 for the users.

 In order to implement this feature, I am going to add four roles at
 dashboard creation time as follows,

- internal/dashboard/{dashboardID}/editor
- internal/dashboard/{dashboardID}/viewer
- internal/dashboard/{dashboardID}/settings
- 

Re: [Architecture] ESB Connector for Asana

[Nirthika Rajendran]

Hi Malaka,

We had a peer review at the Jaffna office. We made the following changes
according to their comments.


   - Change the init method to store the accesstoken in registry.
   - Format the code according to the WSO2 standards.
   - Add the INTEGRATION.txt file.
   - Change the test cases for new init method.

We are all ready, Shall we have the review on next Tuesday (14th of June)
at 4pm?

Thank you

On Tue, Jun 7, 2016 at 12:40 PM, Malaka Silva  wrote:

> Hi Nirthika,
>
> Did we had the review? If not shall we plan for this soon.
>
> On Fri, May 27, 2016 at 10:53 AM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Yes, we can come to the office for review next week
>>
>> Thank you.
>>
>>
>> On Fri, May 27, 2016 at 7:54 AM, Malaka Silva  wrote:
>>
>>> Hi Nirthika,
>>>
>>> Great can we have a review before publishing next week. You can come to
>>> our office or have it via google hangout?
>>>
>>> On Thu, May 26, 2016 at 8:20 PM, Nirthika Rajendran <
>>> nirthika.rajend...@gmail.com> wrote:
>>>
 Hi Malaka,

 We have completed most of the part of asana connector including

1. Develop the methods
2. Implement integration testing.
3. Complete documentation.


 Thank you,
 Nirthika R

 On Wed, May 4, 2016 at 7:45 AM, Malaka Silva  wrote:

> Good progress. Keep us posted.
>
> On Wed, May 4, 2016 at 5:39 AM, Nirthika Rajendran <
> nirthika.rajend...@gmail.com> wrote:
>
>> Hi Malaka,
>>
>> Yesterday we meet our mentor Kesavan to clear some problem in
>> integration test. There we correct some errors and now we continue the 
>> task.
>>
>> Thank you.
>>
>> On Tue, May 3, 2016 at 11:58 AM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> ok, thank you.
>>>
>>> On Tue, May 3, 2016 at 11:21 AM, Malaka Silva 
>>> wrote:
>>>
 After finishing the integration tests should be fine.

 On Tue, May 3, 2016 at 9:18 AM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> Hi Malaka,
>
> Thank you, we already have two mentors Miss. Keerthika and Mr.
> Kesavan. So if we have any other problem we will contact you.
>
> Can we have the hangout after finishing the integration test or it
> is necessary to do now?
>
> Thank you.
>
> On Mon, May 2, 2016 at 9:31 PM, Malaka Silva 
> wrote:
>
>> Hi Nirthika,
>>
>> Let us know if you need any assistance to complete this?
>>
>> We can have a hangout to review the work you have done so far if
>> possible?
>>
>> On Wed, Mar 9, 2016 at 4:08 PM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Thank you Malaka,
>>>
>>> Sure we also expect that.
>>>
>>> On Wed, Mar 9, 2016 at 3:38 PM, Malaka Silva 
>>> wrote:
>>>
 Hi Nirthika,

 Good progress. We are also planning to arrange a meetup at
 Jaffna office in April. Feel free to come.

 On Wed, Mar 9, 2016 at 1:35 PM, Nirthika Rajendran <
 nirthika.rajend...@gmail.com> wrote:

> Hi Malaka,
>
> Every members in my team nearly take 10 methods and do the
> documentation and integration test for their part also.
>
> Now we all finished about 40 methods and user documentation.
>
> This month we have final semi examination, So we plan to
> continue the remaining part after the exam.
>
> Thank you
>
> Regards,
> Nirthika Rajendran
>
>
> On Sun, Feb 21, 2016 at 7:24 AM, Malaka Silva  > wrote:
>
>> Hi Nirthika,
>>
>> ​Good progress.​
>>
>>
>> On Sat, Feb 20, 2016 at 7:51 PM, Nirthika Rajendran <
>> nirthika.rajend...@gmail.com> wrote:
>>
>>> Thank you Malaka,
>>>
>>> Now we finished nearly 35 Methods, and going to develop
>>> documentation.
>>> We contact some staff from Jaffna branch as our mentors (Ms.
>>> M. Keerthika). They also help us
>>>
>>> I will put the time window soon.
>>>
>>> Thank you,
>>> Nirthika Rajendran.
>>>
>>>
>>> On Sat, Feb 20, 2016 at 12:26 PM, Malaka Silva <
>>> mal...@wso2.com> wrote:
>>>
 Looks good. 

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

Hi Tanya,

1) Are we really generating gadgets, though the wizard or generating JSONs?
(I personally don't like the former, as we have discussed before)

2) If we are generating, which files are dynamic generated Vs. which files
are copies? I think it should be possible to figure out by looking at files.

On Tue, Jun 7, 2016 at 5:41 AM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
> Appreciate your input.
>
> Thanks,
> Tanya
>
> --
> Tanya Madurapperuma
>
> Senior Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] WSO2 IS Analytics v1.0.0-ALPHA Released

[Seshika Fernando]

Hi guys,

If we did any changes to the architecture of Authentication analytics, can
we update the documentation in [1].

Damith/Mohan: Can one of you take ownership of this?

Thanks,
Seshi

1.
https://docs.google.com/a/wso2.com/document/d/1h47OLzBiHYy-kk12VkmRnoetbG37Dx4LcHa3CnTzDTE/edit?usp=sharing

On Fri, Jun 3, 2016 at 1:07 PM, Damith Wickramasinghe 
wrote:

> *WSO2 IS Analytics v1.0.0-ALPHA Released*
>
> We are pleased to announce the alpha release of WSO2 IS Analytics v1.0.0 [
> 1
> ]
> which is powered by WSO2 Data Analytics Server. IS Analytics can be used
> to monitor authentication related analytics for residence and federated
> authentication scenarios.[2
> ] Please use the
> nightly build IS pack [3
> ]
> which includes necessary instruments to publish data to analytics IS.Your
> feedback is highly appreciated, any bugs or issues can be reported here [4
> ].
>
> This release contains the following capabilities:-
>
>1. View Authentication analytics for Federated Identity scenarios
>which includes viewing overall success and failure login attempts and
>authentication attempts views for multiple dimensions of Service Provider,
>Identity Providers,Users and also first time login of service Providers.
>2. View Authentication analytics for Federated scenarios which
>includes viewing
>overall success and failure login attempts and authentication attempts
>views for multiple dimensions of service provider, roles , user and
>user-stores
>
> [1]
> https://github.com/wso2/analytics-is/releases/download/v1.0.0-alpha/wso2analytics-is-1.0.0-alpha.zip
> [2] https://docs.wso2.com/display/IS520/WSO2+IS+Analytics
> [3] *https://svn.wso2.org/repos/wso2/people/mohan/is-5.2.0-with-analytics
> *
> [4] *https://wso2.org/jira/browse/ANLYIS
> *
>
>
> Analytics IS Team
>
>
> --
> Software Engineer
> WSO2 Inc.; http://wso2.com
> 
> lean.enterprise.middleware
>
> mobile: *+94728671315 <%2B94728671315>*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [CEP] Extending the Regression Function to support time window

[Seshika Fernando]

No, the existing regression function should remain, as its a different
usecase. There are many instances where we need to perform regression on a
set of events that are not limited by a time duration. In that case, the
existing regression implementation will be used. However, the duration
parameter should be available for outlier and forecast extensions as well.
So a user should be able to use the outlier/forecast regression functions
with/without duration parameter. So your new version should be applicable
to all 3 regression extensions (linear regression, outlier, forecast).

seshi

On Tue, Jun 7, 2016 at 6:32 PM, Charini Nanayakkara 
wrote:

> Hi Seshika, Suho,
>
> Is the existent regression function to be entirely replaced by the new
> one? If so it's necessary to change implementation of outlier and forecast
> extensions as well, since those are based on the regression implementation.
> Furthermore, there's the concern of existent applications being rendered
> useless if the old version is entirely removed. If it's preferred to keep
> both, a new name is required for this extension.  Since the regression
> function supports both time and length, a name such as regressTimeLength
> would be appropriate IMO. Please give your suggestions.
>
> Regards,
> Charini
>
> On Sun, Jun 5, 2016 at 11:28 AM, Seshika Fernando 
> wrote:
>
>> Hi,
>> The length ceiling is necessary along with the duration parameter. The
>> reason the batch size was originally implemented was to optimize
>> performance when large datasets are considered for regression. We need to
>> be able to give an upper bound. So for example in this case, if user uses a
>> large duration (24 hours)and there are millions of events, then if we put a
>> batch size of 1 million it will consider the last 1 million events in the
>> last 24 hours. Which is a valid use case.
>>
>> For this reason, the ability to specify both duration and batch size is
>> important.
>>
>> Seshi
>> On 2 Jun 2016 14:45, "Charini Nanayakkara"  wrote:
>>
>>> Noted with thanks. Will proceed with the implementation likewise.
>>>
>>> Charini
>>>
>>> On Thu, Jun 2, 2016 at 2:28 PM, Sriskandarajah Suhothayan >> > wrote:
>>>
 I think having batchSize & duration will be good as this will limit the
 number of events considered, this can help to improve performance as well.

 Suho

 On Thu, Jun 2, 2016 at 1:59 PM, Charini Nanayakkara 
 wrote:

> Hi Tishan,
>
> For my requirement, having time window alone is adequate. So your
> point might be valid. However I'm concerned of the re-usability of the
> extension.
>
> @Srinath, WDYT? Which would be the better option? Having a single
> implementation or two different ones?
>
> Thanks
>
> On Thu, Jun 2, 2016 at 1:48 PM, Tishan Dahanayakage 
> wrote:
>
>> Charini,
>>
>> My knowledge on the on this domain is sparse. Hence I do not know
>> whether a scenario where time AND length is a valid business case. If it 
>> is
>> a valid business case +1 for the design including both parameters in same
>> implementation.
>>
>> Thanks
>> /Tishan
>>
>> On Thu, Jun 2, 2016 at 12:54 PM, Charini Nanayakkara <
>> chari...@wso2.com> wrote:
>>
>>> Hi Tishan,
>>>
>>> Yes. Assuming batch size is 5 and time window is 20 mins, only 5 out
>>> of 10 events which arrive within last 5 mins would be processed due to
>>> batch size constraint (even though all events must be processed if time
>>> alone was considered). Having separate implementations would work on the
>>> majority of the scenarios, since only time OR length is usually 
>>> applicable
>>> but not both. However, having two implementations would cause trouble in
>>> the situations where both the time factor and length are important
>>> (equivalent to AND operation on the two constraints). If our 
>>> requirement is
>>> to have only one of the two constraints, we can use a very large value 
>>> for
>>> the other parameter (i.e. if we only need to limit number of events 
>>> based
>>> on time = 1 sec constraint, we can specify 1,000,000 for batch size
>>> assuming we have prior knowledge that 1,000,000 events would never 
>>> arrive
>>> within 1 sec). IMHO neither of the two options (separate or single
>>> implementation) are perfect for every scenario. However having a single
>>> implementation would help address more cases as I understand. What's 
>>> your
>>> opinion on this?
>>>
>>> Thanks
>>>
>>> On Thu, Jun 2, 2016 at 10:14 AM, Charini Nanayakkara <
>>> chari...@wso2.com> wrote:
>>>
 Hi All,

 I have planned to extend the existent Regression Function by adding
 time parameter. Regression is a functionality 

Re: [Architecture] Feature - Applying a custom theme for a dashboard

[Sinthuja Ragendran]

Hi Jerad et all,

Let's use this approach if we want to apply some custom theme per
dashboard, without modifying the default theme. I know as we have merged
the theme you guys have developed for analytics effort as default theme, it
should not be a issue now. :) But in case, if you come across future
requirements, let's utilize this.

Thanks,
Sinthuja.

On Mon, Jun 6, 2016 at 6:34 AM, Prabushi Samarakoon 
wrote:

> Hi all,
>
> With the new release WSO2 DS 2.1.0 M2, we have introduced the support for
> applying a custom theme per dashboard in WSO2 Dashboard Server.
>
> User can deploy their custom themes as a Carbon Application Archive file
> through the admin console. One of these deployed themes can be selected as
> the dashboard theme, when the user create a dashboard. User can also change
> the selected theme, using dashboard settings configurations. Users are
> allowed to add a custom theme, only for the view of the dashboard. Users
> can add their own script files, template files and styles to customize the
> view of a particular dashboard.
>
> Further details about this feature can be found in the document attached
> here.
>
> Thanks,
> Prabushi
>
> --
> *Prabushi Samarakoon*
> Software Engineer
> Mobile: +94715434580
> Email: prabus...@wso2.com
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [CEP] Extending the Regression Function to support time window

[Charini Nanayakkara]

Hi Seshika, Suho,

Is the existent regression function to be entirely replaced by the new one?
If so it's necessary to change implementation of outlier and forecast
extensions as well, since those are based on the regression implementation.
Furthermore, there's the concern of existent applications being rendered
useless if the old version is entirely removed. If it's preferred to keep
both, a new name is required for this extension.  Since the regression
function supports both time and length, a name such as regressTimeLength
would be appropriate IMO. Please give your suggestions.

Regards,
Charini

On Sun, Jun 5, 2016 at 11:28 AM, Seshika Fernando  wrote:

> Hi,
> The length ceiling is necessary along with the duration parameter. The
> reason the batch size was originally implemented was to optimize
> performance when large datasets are considered for regression. We need to
> be able to give an upper bound. So for example in this case, if user uses a
> large duration (24 hours)and there are millions of events, then if we put a
> batch size of 1 million it will consider the last 1 million events in the
> last 24 hours. Which is a valid use case.
>
> For this reason, the ability to specify both duration and batch size is
> important.
>
> Seshi
> On 2 Jun 2016 14:45, "Charini Nanayakkara"  wrote:
>
>> Noted with thanks. Will proceed with the implementation likewise.
>>
>> Charini
>>
>> On Thu, Jun 2, 2016 at 2:28 PM, Sriskandarajah Suhothayan 
>> wrote:
>>
>>> I think having batchSize & duration will be good as this will limit the
>>> number of events considered, this can help to improve performance as well.
>>>
>>> Suho
>>>
>>> On Thu, Jun 2, 2016 at 1:59 PM, Charini Nanayakkara 
>>> wrote:
>>>
 Hi Tishan,

 For my requirement, having time window alone is adequate. So your point
 might be valid. However I'm concerned of the re-usability of the extension.

 @Srinath, WDYT? Which would be the better option? Having a single
 implementation or two different ones?

 Thanks

 On Thu, Jun 2, 2016 at 1:48 PM, Tishan Dahanayakage 
 wrote:

> Charini,
>
> My knowledge on the on this domain is sparse. Hence I do not know
> whether a scenario where time AND length is a valid business case. If it 
> is
> a valid business case +1 for the design including both parameters in same
> implementation.
>
> Thanks
> /Tishan
>
> On Thu, Jun 2, 2016 at 12:54 PM, Charini Nanayakkara <
> chari...@wso2.com> wrote:
>
>> Hi Tishan,
>>
>> Yes. Assuming batch size is 5 and time window is 20 mins, only 5 out
>> of 10 events which arrive within last 5 mins would be processed due to
>> batch size constraint (even though all events must be processed if time
>> alone was considered). Having separate implementations would work on the
>> majority of the scenarios, since only time OR length is usually 
>> applicable
>> but not both. However, having two implementations would cause trouble in
>> the situations where both the time factor and length are important
>> (equivalent to AND operation on the two constraints). If our requirement 
>> is
>> to have only one of the two constraints, we can use a very large value 
>> for
>> the other parameter (i.e. if we only need to limit number of events based
>> on time = 1 sec constraint, we can specify 1,000,000 for batch size
>> assuming we have prior knowledge that 1,000,000 events would never arrive
>> within 1 sec). IMHO neither of the two options (separate or single
>> implementation) are perfect for every scenario. However having a single
>> implementation would help address more cases as I understand. What's your
>> opinion on this?
>>
>> Thanks
>>
>> On Thu, Jun 2, 2016 at 10:14 AM, Charini Nanayakkara <
>> chari...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> I have planned to extend the existent Regression Function by adding
>>> time parameter. Regression is a functionality available for the Siddhi
>>> stream processor extension known as timeseries. In the current
>>> implementation, the regression function consumes two or more parameters 
>>> and
>>> performs regression as follows.
>>>
>>> The mandatory parameters to be given are the dependent attribute Y
>>> and the independent attribute(s) X1, X2,Xn. For performing simple
>>> linear regression, merely one independent attribute would be given. Two 
>>> or
>>> more independent attributes are consumed for executing multiple linear
>>> regression.
>>>
>>> timeseries:regress(Y, X1, X2..,Xn)
>>>
>>> The other three optional parameters to be specified are calculation
>>> interval, batch size and confidence interval (ci). In the case where 
>>> those
>>> are not 

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

Thank you for your inputs.

@ Dakshika :
Based on your input following modifications were made.

*Chart template structure*

└── line-chart
├── api.js
├── config.json
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
└── line-chart.js


*Generated gadget structure*

└── test_gadget
├── conf.json
├── gadget-controller.jag
├── gadget.json
├── index.png
├── index.xml
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
├── core-js
│   ├── gadget-core.js
│   ├── line-chart-api.js
│   └── provider-api.js
└── line-chart.js


*Folder structure for storing common libs*

portal
  |── libs

  ├── vendorName_version
  │   ├── 


*Changes to the existing model*

   - common libs will reside inside portal/libs/

*chart config.json*

"common": {
"js": ["vendorName_version/common"],
"css": ["vendorName_version/common"]
},
"chart": {
"js": ["vendorName_version/d3.min", "vendorName_version/vega",
"line-chart"],
"css": ["vendorName_version/graph, line-chart"]
}

"common" is for libs fetched from /portal/libs
"chart" is for both chart specfic libs inside js folder of chart template
and chart-libs that are coming from vendors.

So with the change suggested by Dakshika we will have to specify the
directory path of chart-libs in the config.json (ex:
 "vendorName_version/d3.min" )
But if it is a chart specific js file (in this example line-chart.js)
specifying the file name is enough.

In the gadget xml of the generated gadget we will be using the relative
path for libs fetched from /portal/libs.

@ Suho : Yes, the gadgets generated via old wizard will still work, I was
worried about the consistency between old gadgets and new gadgets generated
via the wizard. As per the offline chat we had, no obligations from IOT
side.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com

On Tue, Jun 7, 2016 at 3:53 PM, Dakshika Jayathilaka 
wrote:

> Hi All,
>
> IMO it's better if we can maintain third-party libraries as a separate
> entity. Usually, most of the third party libs have their own dependencies
> (ex: some CSS files refer images/ fonts ). If we place them separately it's
> hard to identify relevant dependency at a glance.
>
>  At the same time, I would like to propose to have library version as
> well. This will really useful if someone wants to upgrade third-party lib
> etc.
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Senior Software Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing 

Re: [Architecture] Do we need a House Keeping Task for C5 Based Products

[Afkham Azeez]

I think we should rely on the components that create garbage to clear out
their own garbage without having a central task in the kernel.

On Tue, Jun 7, 2016 at 3:29 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi All,
>
> I'm trying to implement file upload support for msf4j with FormParam. In
> the none streaming mode, we need to create temp files in some location and
> clean them after a particular time period.
>
> For that purpose at the moment I'm using apache commons-io provided
> FileCleaningTracker[1, 2]. There we can give the set of file objects that
> we need to track. This will be running in a separate thread. When those
> objects are eligible for GC, it will delete the those files. In this way we
> can be sure that the temp objects will not get clear before the actual
> service consumes them.
>
> IMHO it would be much easier if we can provide a similar support from the
> kernel level, since products will require similar functionality in the
> future.
>
> AFAIU rather than tracking the file object references, if we run this as a
> periodic task (like in c4) we have to assume that the temp files are been
> consumed after a pre-configured time. Is it safe to assume so?
>
> WDYT?
>
> [1] -
> https://commons.apache.org/proper/commons-io/javadocs/api-2.2/org/apache/commons/io/FileCleaningTracker.html
> [2] -
> https://github.com/apache/commons-io/blob/trunk/src/main/java/org/apache/commons/io/FileCleaningTracker.java
>
> Thanks
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **http://lk.linkedin.com/in/afkhamazeez
*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Sinthuja Ragendran]

According to the chat I had with Johann, we have came up with this model.
Basically as per now in C4 we don't have a way to add a permission
dynamically, and similar requirement has been raised in IS as well and they
have come up with this model.

The main reason for this is, there might be some dashboard that you are
working on and want to share between some users and grant some privileges.
It's not doable with global permission, bcz having an edit permission for
say sales dashboard doesn't mean you have the permission for admin
dashboard. Therefore this needs to be controlled per dashboard, not
globally.

Thanks,
Sinthuja.

On Tue, Jun 7, 2016 at 11:12 AM, Sriskandarajah Suhothayan 
wrote:

> Why are we not using different permissions for each dashboard than using
>  roles. I believe using permissions will be more scalable than using roles.
> WDYT?
>
> Regards
> Suho
>
> On Tue, Jun 7, 2016 at 2:38 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi Udara,
>>
>> Since these are internal roles, they are not stored in LDAP. So it will
>> work fine.
>>
>> Thanks,
>> Nisala
>>
>> On Tue, Jun 7, 2016 at 10:57 AM, Udara Rathnayake 
>> wrote:
>>
>>> Another question, ​Is this going to work if we have to connect to a
>>> read-only LDAP/A
>>> ​D​
>>> userstore?
>>>
>>> On Tue, Jun 7, 2016 at 9:43 AM, Tanya Madurapperuma 
>>> wrote:
>>>
 Is this model scalable? Because per dashboard we will have to create 4
 internal roles. So if we have N number of dashboards we will end up having
 4 * N number of internal roles.

 @ IS team : is this approach fine? Or is there any better approach?

 Thanks,
 Tanya

 On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara 
 wrote:

> adding Johan and Manuranga
>
> Thanks,
> Nisala
>
> On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> I am working on implementing an access levels model for WSO2
>> Dashboard Server. Currently global permission model for 
>> create/delete/login
>> is implemented by Megala. Since it does not support to provide per
>> dashboard level access for the users. I am going to extend it and 
>> implement
>> a permission model that can be used to provide per dashboard level access
>> for the users.
>>
>> In order to implement this feature, I am going to add four roles at
>> dashboard creation time as follows,
>>
>>- internal/dashboard/{dashboardID}/editor
>>- internal/dashboard/{dashboardID}/viewer
>>- internal/dashboard/{dashboardID}/settings
>>- internal/dashboard/{dashboardID}/delete
>>
>> At the dashboard creation time, the user who creates the dashboard
>> will get all the four roles. But other users have to get above roles to 
>> do
>> appropriate actions to the dashboard. So that we can set above four roles
>> for the users and They will be given different access levels according to
>> their roles.
>>
>> Please feel free to give any feedback.
>>
>> Thanks,
>> Nisala
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>



 --
 Tanya Madurapperuma

 Senior Software Engineer,
 WSO2 Inc. : wso2.com
 Mobile : +94718184439
 Blog : http://tanyamadurapperuma.blogspot.com

>>>
>>>
>>>
>>> --
>>> Regards,
>>> UdaraR
>>>
>>
>>
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *S. Suhothayan*
> Technical Lead & Team Lead of WSO2 Complex Event Processor
> *WSO2 Inc. *http://wso2.com
> * *
> lean . enterprise . middleware
>
>
> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
> http://suhothayan.blogspot.com/ twitter:
> http://twitter.com/suhothayan  | linked-in:
> http://lk.linkedin.com/in/suhothayan *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APPM] One time download link support for mobile app install/download

[Ruwan Abeykoon]

Hi All,
I think we need to have TTL (Time To Live/Expiry time)  for each OTDL.
Download link used after the expiry time should be denied. The generate
OTDL API call can carry the TTL parameter optionally.

Cheers,
Ruwan



On Tue, Jun 7, 2016 at 10:42 AM, Chathura Dilan  wrote:

> Hi Thilini,
>
> +1 for this approach
>
>
>
> Please see my comments inline
>
>
>
> 1. The generated download link is not secured since it is a one-time
> download link. Is there a security concern regarding this approach?
>
> There is no major security issue in this approach. I'm adding Prabath for
> more ideas
>
>
>
> 2. According to above, a single user will have to generate separate app
> download links, in a case where he has several devices to download the app.
> In that case, are we going to limit
>
> User should be able to generate multiple download links from one request.
> But we can introduce a throttling mechanism for app installation requests
> for security purpose.
>
>
>
> 3. Are we going to persist the details of the device (device id) that the
> download link had been generated for so that we can enforce the security?
>
> It's good if we can persist the download request for analytics purposes.
> IMO we don't need to persist other information like device ID.
>
>
>
>
>
>
>
>
>
> On Tue, Jun 7, 2016 at 9:31 AM, Lahiru Cooray  wrote:
>
>>
>>
>> On Tue, Jun 7, 2016 at 9:12 AM, Thilini Shanika 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to implement one-time app download link support for
>>> mobile application installation/download in App Manager 1.2.0. The main
>>> objective of introducing this feature is to overcome security issues with
>>> the current approach of installing mobile apps.
>>>
>>> Below is the designed approach of achieving $Subject.
>>> ​
>>> ​
>>> According to above,
>>>
>>>- User login to App Store and make subscription/installation to a
>>>particular mobile app
>>>- One time download link is generated for the user
>>>(/binaries/one-time/{UUID}) and the mapping of generated UUID and
>>>the actual binary file is persisted in a Database table. The status of 
>>> the
>>>download will be marked as 0 to indicate that the download link has not
>>>been used yet.
>>>- The device will access the binary download API via the generated
>>>UUID to install the app. When the download/installation is completed, the
>>>status of the binary downloadable URL reference will be marked as 1 to
>>>indicate it has been used once. After an app download, any other access 
>>> to
>>>the link will be prohibited.
>>>
>>>
>>> There are few concerns regarding the implementation.
>>>
>>>- The generated download link is not secured since it is a one-time
>>>download link. Is there a security concern regarding this approach?
>>>- According to above, a single user will have to generate separate
>>>app download links, in a case where he has several devices to download 
>>> the
>>>app. In that case, are we going to limit (Configurable limit) the number 
>>> of
>>>download links that can  be generated by a single user?
>>>
>>> AFAIK we use the same operation to perform the enterprise installation
>> as well, where an admin user can install an App to several users/devices.
>> In that case I don't think limiting generation of download links user wise
>> would be a good option (unless we consider the devices as well)
>>
>>>
>>>- Are we going to persist the details of the device (device id) that
>>>the download link had been generated for so that we can enforce the
>>>security?
>>>
>>> +1
>>
>>> Your comments and suggestions are highly appreciated.
>>>
>>> Thanks
>>> Thilini
>>>
>>>
>>> --
>>> Thilini Shanika
>>> Senior Software Engineer
>>> WSO2, Inc.; http://wso2.com
>>> 20, Palmgrove Avenue, Colombo 3
>>>
>>> E-mail: tgtshan...@gmail.com
>>> ​
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Lahiru Cooray*
>> Software Engineer
>> WSO2, Inc.;http://wso2.com/
>> lean.enterprise.middleware
>>
>> Mobile: +94 715 654154
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
>
> Chatura Dilan Perera
> *Associate Tech Lead** - WSO2 Inc.*
> www.dilan.me
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*

email: ruw...@wso2.com
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Dakshika Jayathilaka]

Hi All,

IMO it's better if we can maintain third-party libraries as a separate
entity. Usually, most of the third party libs have their own dependencies
(ex: some CSS files refer images/ fonts ). If we place them separately it's
hard to identify relevant dependency at a glance.

 At the same time, I would like to propose to have library version as well.
This will really useful if someone wants to upgrade third-party lib etc.

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Senior Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
> Appreciate your input.
>
> Thanks,
> Tanya
>
> --
> Tanya Madurapperuma
>
> Senior Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Sriskandarajah Suhothayan]

Gadget generation API  is orthogonal to the usage API and we are not
changing the usage API, hence gadget created via old generation tools will
still work.

Regards
Suho

On Tue, Jun 7, 2016 at 3:34 PM, Rajith Vitharana  wrote:

> Hi Tanya,
>
> On Tue, Jun 7, 2016 at 3:21 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Rajith,
>>
>> We have not done any GA release, not even an Alpha release of the product
>> with this, but a component repo release.
>>
> Still if this is a API change to a component which we already released to
> public, I feel we have to think of those aspects as well. (Conflicts
> happens only if some one is going to use it, hence kind of taking a chance
> doing such release, if we can't 100% sure no one will going to use that) or
> else we may need to provide migration (support when/if) needed. Just my two
> cents :)
>
> Thanks,
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Sriskandarajah Suhothayan]

Why are we not using different permissions for each dashboard than using
 roles. I believe using permissions will be more scalable than using roles.
WDYT?

Regards
Suho

On Tue, Jun 7, 2016 at 2:38 PM, Nisala Nanayakkara  wrote:

> Hi Udara,
>
> Since these are internal roles, they are not stored in LDAP. So it will
> work fine.
>
> Thanks,
> Nisala
>
> On Tue, Jun 7, 2016 at 10:57 AM, Udara Rathnayake  wrote:
>
>> Another question, ​Is this going to work if we have to connect to a
>> read-only LDAP/A
>> ​D​
>> userstore?
>>
>> On Tue, Jun 7, 2016 at 9:43 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Is this model scalable? Because per dashboard we will have to create 4
>>> internal roles. So if we have N number of dashboards we will end up having
>>> 4 * N number of internal roles.
>>>
>>> @ IS team : is this approach fine? Or is there any better approach?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 adding Johan and Manuranga

 Thanks,
 Nisala

 On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
 wrote:

> Hi all,
>
> I am working on implementing an access levels model for WSO2 Dashboard
> Server. Currently global permission model for create/delete/login is
> implemented by Megala. Since it does not support to provide per dashboard
> level access for the users. I am going to extend it and implement a
> permission model that can be used to provide per dashboard level access 
> for
> the users.
>
> In order to implement this feature, I am going to add four roles at
> dashboard creation time as follows,
>
>- internal/dashboard/{dashboardID}/editor
>- internal/dashboard/{dashboardID}/viewer
>- internal/dashboard/{dashboardID}/settings
>- internal/dashboard/{dashboardID}/delete
>
> At the dashboard creation time, the user who creates the dashboard
> will get all the four roles. But other users have to get above roles to do
> appropriate actions to the dashboard. So that we can set above four roles
> for the users and They will be given different access levels according to
> their roles.
>
> Please feel free to give any feedback.
>
> Thanks,
> Nisala
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>



 --
 *Nisala Niroshana Nanayakkara,*
 Software Engineer
 Mobile:(+94)717600022
 WSO2 Inc., http://wso2.com/

>>>
>>>
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Senior Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>> Blog : http://tanyamadurapperuma.blogspot.com
>>>
>>
>>
>>
>> --
>> Regards,
>> UdaraR
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Rajith Vitharana]

Hi Tanya,

On Tue, Jun 7, 2016 at 3:21 PM, Tanya Madurapperuma  wrote:

> Hi Rajith,
>
> We have not done any GA release, not even an Alpha release of the product
> with this, but a component repo release.
>
Still if this is a API change to a component which we already released to
public, I feel we have to think of those aspects as well. (Conflicts
happens only if some one is going to use it, hence kind of taking a chance
doing such release, if we can't 100% sure no one will going to use that) or
else we may need to provide migration (support when/if) needed. Just my two
cents :)

Thanks,

-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Do we need a House Keeping Task for C5 Based Products

[Thusitha Thilina Dayaratne]

Hi All,

I'm trying to implement file upload support for msf4j with FormParam. In
the none streaming mode, we need to create temp files in some location and
clean them after a particular time period.

For that purpose at the moment I'm using apache commons-io provided
FileCleaningTracker[1, 2]. There we can give the set of file objects that
we need to track. This will be running in a separate thread. When those
objects are eligible for GC, it will delete the those files. In this way we
can be sure that the temp objects will not get clear before the actual
service consumes them.

IMHO it would be much easier if we can provide a similar support from the
kernel level, since products will require similar functionality in the
future.

AFAIU rather than tracking the file object references, if we run this as a
periodic task (like in c4) we have to assume that the temp files are been
consumed after a pre-configured time. Is it safe to assume so?

WDYT?

[1] -
https://commons.apache.org/proper/commons-io/javadocs/api-2.2/org/apache/commons/io/FileCleaningTracker.html
[2] -
https://github.com/apache/commons-io/blob/trunk/src/main/java/org/apache/commons/io/FileCleaningTracker.java

Thanks
-- 
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Rajith,

We have not done any GA release, not even an Alpha release of the product
with this, but a component repo release.

Thanks,
Tanya

On Tue, Jun 7, 2016 at 3:17 PM, Rajith Vitharana  wrote:

> Hi Tanya,
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
> If we have released a version with earlier method, there may be people
> using it in future(even though only IOT is using that for now) so it's
> better to think of a migration process as well. Or else proper
> documentation and ask not to use earlier version (which I feel is not a
> good thing)
>
> Thanks,
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Rajith Vitharana]

Hi Tanya,

On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
If we have released a version with earlier method, there may be people
using it in future(even though only IOT is using that for now) so it's
better to think of a migration process as well. Or else proper
documentation and ask not to use earlier version (which I feel is not a
good thing)

Thanks,

-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

During an offline discussion with Jerad following modification were
suggested regarding the directory structure of the extension model. All
these changes are subjected to js and css file locations.

*Chart template structure*

|── line-chart
  │   ├── css
  │   │   └── line-chart.css
  │   └── js
  │   ├── d3.min.js
  │   ├── vega.js
  │   └── VizGrammar.min.js
   |── config.json
  ├── api.js


*Changes to the existing model*

   - rename index.js to api.js
   - rename chart-libs folder to js
   - have a css folder in the same level


*Generated gadget structure*

└── test_gadget
│   │   ├── conf.json
│   │   ├── css
│   │   │   └── line-chart.css
│   │   ├── gadget-controller.jag
│   │   ├── gadget.json
│   │   ├── index.png
│   │   ├── index.xml
│   │   └── js
│   │   ├── core
│   │   │   ├── gadget-core.js
│   │   │   ├── line-chart-api.js
│   │   │   └── provider-api.js
│   │   ├── d3.min.js
│   │   ├── vega.js
│   │   └── VizGrammar.min.js


*Changes to the existing model*

   - Instead of the *chart-libs* folder inside *js* folder, have a
*core *folder
   inside *js *folder and place chart specific js files in js folder


*Folder structure for storing common libs*

portal
  |── gadget-commons

   ├── css
   │   └── common.css
   └── js
   └── common.js


*Changes to the existing model*

   - Now we have common libs inside portal/libs/common-chart-libs/

*chart config.json*

"common": {
"js": ["common"],
"css": ["common"]
},
"chart": {
"js": ["d3.min", "vega", "VizGrammar.min"],
"css": ["line-chart"]
}

*existing config.json*

"common-libs" : ["wso2gadgets","chart-utils"],
"chart-libs" : ["d3.min","vega","VizGrammar.min"]

I think this model is cleaner and intuitive than the exiting model.
AFAIK existing wizard is only used for IOT analytics. If there are no
concerns from them shall we move to this new model?

@ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
Appreciate your input.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Susinda Perera]

What is the requirement to have per dashboard permission model. What if we
go with only four roles (global). I think in Api manager we can edit one
api created by one user, by some other user (having create permissions). We
can limit acess by tenant level. Will something like that works here.

On Tue, Jun 7, 2016 at 2:38 PM, Nisala Nanayakkara  wrote:

> Hi Udara,
>
> Since these are internal roles, they are not stored in LDAP. So it will
> work fine.
>
> Thanks,
> Nisala
>
> On Tue, Jun 7, 2016 at 10:57 AM, Udara Rathnayake  wrote:
>
>> Another question, ​Is this going to work if we have to connect to a
>> read-only LDAP/A
>> ​D​
>> userstore?
>>
>> On Tue, Jun 7, 2016 at 9:43 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Is this model scalable? Because per dashboard we will have to create 4
>>> internal roles. So if we have N number of dashboards we will end up having
>>> 4 * N number of internal roles.
>>>
>>> @ IS team : is this approach fine? Or is there any better approach?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 adding Johan and Manuranga

 Thanks,
 Nisala

 On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
 wrote:

> Hi all,
>
> I am working on implementing an access levels model for WSO2 Dashboard
> Server. Currently global permission model for create/delete/login is
> implemented by Megala. Since it does not support to provide per dashboard
> level access for the users. I am going to extend it and implement a
> permission model that can be used to provide per dashboard level access 
> for
> the users.
>
> In order to implement this feature, I am going to add four roles at
> dashboard creation time as follows,
>
>- internal/dashboard/{dashboardID}/editor
>- internal/dashboard/{dashboardID}/viewer
>- internal/dashboard/{dashboardID}/settings
>- internal/dashboard/{dashboardID}/delete
>
> At the dashboard creation time, the user who creates the dashboard
> will get all the four roles. But other users have to get above roles to do
> appropriate actions to the dashboard. So that we can set above four roles
> for the users and They will be given different access levels according to
> their roles.
>
> Please feel free to give any feedback.
>
> Thanks,
> Nisala
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>



 --
 *Nisala Niroshana Nanayakkara,*
 Software Engineer
 Mobile:(+94)717600022
 WSO2 Inc., http://wso2.com/

>>>
>>>
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Senior Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>> Blog : http://tanyamadurapperuma.blogspot.com
>>>
>>
>>
>>
>> --
>> Regards,
>> UdaraR
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Susinda Perera*
Software Engineer
B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL)
Mobile:(+94)716049075
Blog: susinda.blogspot.com
WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Nisala Nanayakkara]

Hi Udara,

Since these are internal roles, they are not stored in LDAP. So it will
work fine.

Thanks,
Nisala

On Tue, Jun 7, 2016 at 10:57 AM, Udara Rathnayake  wrote:

> Another question, ​Is this going to work if we have to connect to a
> read-only LDAP/A
> ​D​
> userstore?
>
> On Tue, Jun 7, 2016 at 9:43 AM, Tanya Madurapperuma 
> wrote:
>
>> Is this model scalable? Because per dashboard we will have to create 4
>> internal roles. So if we have N number of dashboards we will end up having
>> 4 * N number of internal roles.
>>
>> @ IS team : is this approach fine? Or is there any better approach?
>>
>> Thanks,
>> Tanya
>>
>> On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> adding Johan and Manuranga
>>>
>>> Thanks,
>>> Nisala
>>>
>>> On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi all,

 I am working on implementing an access levels model for WSO2 Dashboard
 Server. Currently global permission model for create/delete/login is
 implemented by Megala. Since it does not support to provide per dashboard
 level access for the users. I am going to extend it and implement a
 permission model that can be used to provide per dashboard level access for
 the users.

 In order to implement this feature, I am going to add four roles at
 dashboard creation time as follows,

- internal/dashboard/{dashboardID}/editor
- internal/dashboard/{dashboardID}/viewer
- internal/dashboard/{dashboardID}/settings
- internal/dashboard/{dashboardID}/delete

 At the dashboard creation time, the user who creates the dashboard will
 get all the four roles. But other users have to get above roles to do
 appropriate actions to the dashboard. So that we can set above four roles
 for the users and They will be given different access levels according to
 their roles.

 Please feel free to give any feedback.

 Thanks,
 Nisala
 --
 *Nisala Niroshana Nanayakkara,*
 Software Engineer
 Mobile:(+94)717600022
 WSO2 Inc., http://wso2.com/

>>>
>>>
>>>
>>> --
>>> *Nisala Niroshana Nanayakkara,*
>>> Software Engineer
>>> Mobile:(+94)717600022
>>> WSO2 Inc., http://wso2.com/
>>>
>>
>>
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> Regards,
> UdaraR
>



-- 
*Nisala Niroshana Nanayakkara,*
Software Engineer
Mobile:(+94)717600022
WSO2 Inc., http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dep sync strategies for Carbon 4 products in Kubernetes

[Chamila De Alwis]

Hi Gayan,


On Tue, Jun 7, 2016 at 12:11 PM, Gayan Gunarathne  wrote:

>
> Do we have option get the update only if the changes happen? Without doing
> a loop in a particular period. Specially this will be needed for the multi
> tenant scenario to minimize the cpu utilization.
>

>From the Worker's POV it's not possible to detect if the Manager updated
any artifacts, unless there is a cluster message (which doesn't get
published if SVNDepSync is disabled). AFAIK this kind of a messaging model
would be included in C5.


>
>>
>>>
>>> ​
>>> The problem with these two approaches is that it depends on a single GW
>>> manager node. For the push method, multiple GW managers should not
>>> repeatedly do Rsync calls to the workers. In the pull method, if multiple
>>> GW manager nodes are present (and fronted with a load balancer with
>>> Active/Passive failover), they should have the artifacts synchronized. This
>>> could be possible using a hostPath volume between the GW Manager pod
>>> replicas however, it is yet to be tested.
>>>
>>> Additionally, Kubernetes supports a volume plugin named Git Volume [2],
>>> which is basically an emptyDir volume with an initial "git clone" command
>>> done on the provided remote repository.
>>>
>>
>
> Can we do it with docker containers perspective without tightly coupled to
> Kubernetes. Can we use container mounts to achieve this? If we can use that
> we can use it with docker compose and mesosphere etc.
>

Docker volumes are different from Kubernetes volumes, and it's not easy to
transfer volumes between nodes, when Kubernetes decides to move the pods or
spawn new replicas in different nodes. IMO the approach should be platform
specific.



Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Supporting user information recovery scenarios in IS user portal

[Thanuja Jayasinghe]

Hi Omindu,

Yes. We can't use reCaptcha without internet. But the chance of having Bots
attack from a internal network is very less. So we can either disable
reCaptcha when server is not connect to the internet or have the old
captcha implementation.

+1 for keep the existing captcha implementation. But we have to modify
login, self-registration and recovery flows to add captcha/reCaptcha in a
pluggable manner.

Thanks,
Thanuja.

On Tue, Jun 7, 2016 at 11:14 AM, Isura Karunaratne  wrote:

> Hi,
>
> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera 
> wrote:
>
>> Hi Isura,
>>
>> Since reCaptcha requires to call Google's services for captcha generation
>> and validation, we won't be able to use the dashboard with captcha when we
>> are running IS in an environment without internet connectivity. I'm
>> assuming we are not shipping the old captcha implementation in 5.3.0 so a
>> user will not be able to switch to an internally managed captcha
>> implementation with a simple config change.
>>
>> It'll be good if we can make the old captcha implementation (or a similar
>> implementation) available (by means of an extension or a sample maybe ?) so
>> a user can switch to an internally managed captcha model without much work.
>> WDYT ?
>>
>
> +1. but, we better to decouple old captcha implementation with recovery
> flows.
>
> Thanks
> Isura
>
>
>> Regards,
>> Omindu.
>>
>> On Sun, Jun 5, 2016 at 12:35 PM, Malithi Edirisinghe 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Noted.
>>>
>>> I've got one more concern.
>>> Initially, as you may have noted in the top most mail, recovery
>>> scenarios were to be supported in the login page of the end user
>>> dashboard in IS. But in a consecutive discussion it was highlighted that
>>> these options should be provided in the default SSO login page. Thus, upon
>>> a successful recovery or registration, the flow should be as below.
>>>
>>>1. End user will be redirected to the login page.
>>>2. End user will enter the credentials
>>>3. End user is authenticated and upon successful authentication user
>>>will be redirected to the Service Provider application (Ex: ACS url of 
>>> the
>>>SP).
>>>
>>> So at the moment, we are using the param 'sessionDataKey' to map the
>>> server session across modules, which can be used even here to retrieve the
>>> respective Service Provider who initiated the flow. But, when it comes to
>>> recovery with notifications there is no parameter being communicated to
>>> identify the respective Service Provider. Can we please address this also,
>>> along with this effort ?
>>>
>>> Thanks,
>>> Malithi.
>>>
>>> On Sun, Jun 5, 2016 at 8:39 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Malithi,

 These steps seem to be ok. However we are going to move from KAPCHA to
 google reCaptcha in IS 5.3.0 and this captcha implementation is decoupled
 with each flow you mentioned. So, in new implementation captcha validation
 will happen before invoking to the backend APIs.

 In "security questions based password recovery flow", we are going to
 add a new parameter to parameterize the minimum number of questions that
 user should be answered to recover the password. In the previous releases
 (IS 5, IS5.1.0) this is an application side configuration and it was not a
 server side configuration. With IS 5.3.0 onwards tenant admin can define
 the minimum number of questions that user should be answered to recover the
 password.

 Thanks
 Isura



 On Fri, Apr 29, 2016 at 11:40 AM, Malithi Edirisinghe <
 malit...@wso2.com> wrote:

> Hi All,
>
> We are working on $subject.
>
> So with this, we will be supporting below options in the login page of
> the end user dashboard in IS.
>
>1. Forgot Password (Password Recovery)
>2. Forgot Username (Username Recovery)
>3. Create an account (Self Signup)
>
> Below I have listed the user stories that we identified, to support
> each option above.
>
> *Password Recovery*
>
> With the existing information recovery service implementation we can
> support two options.
> Visibility of each option would be decided on the availability of
> required configurations and required user information.
>
>- Password recovery with an email notification (Email transport
>configuration are required and the user should have a valid email 
> address)
>- Password recovery with security questions (User should have
>preconfigured security questions)
>
> *User story for password recovery with email notification*
>
>1. User views a generated captcha
>2. User enters the captcha answer and submit
>3. Server verifies the captcha answer and sends an email
>notification with the confirmation code
>4. User clicks on 

Re: [Architecture] [Dev] Nullable Support for JSON schema - Visual Data Mapper Editor

[Sohani Weerasinghe]

Sohani Weerasinghe
Senior Software Engineer
WSO2, Inc: http://wso2.com

Mobile  : +94 716439774
Blog :http://christinetechtips.blogspot.com/
Twitter  : https://twitter.com/sohanichristine

On Tue, Jun 7, 2016 at 10:45 AM, Malaka Silva  wrote:

> Hi Sohani,
>
> I guess we are dealing with optional input/output here. So in that case
> are we showing those in a different color or anyway to distinguish?
>
@Malaka: Yes, we are going to use a different icon for those nodes.
eg: If it's an element, then the icon will be something created based on
the previous icon used for the element, so that it will be displayed as an
element with nullable

>
> On execution side this needs to be handled from data mapper mediator.
>
> On Tue, Jun 7, 2016 at 9:21 AM, Sohani Weerasinghe 
> wrote:
>
>> Hi All,
>>
>> We are in a process of implementing the $subject and please find the
>> implementation details.
>>
>> *Input*:
>>
>> http://www.w3.org/TR/html4/;>
>> sample
>> 011265565501
>> 011265565501
>> 
>>
>> After loading the above payload, the generated schema will be as follows
>>
>> {
>>   "$schema" : "http://json-schema.org/draft-04/schema#;,
>>   *"nullable" : "false"*,
>>   "id" : "http://wso2jsonschema.org;,
>>   "title" : "h:person",
>>   "type" : "object",
>>   "properties" : {
>> "firstName" : {
>>   *"nullable" : "false",*
>>   "id" : "http://wso2jsonschema.org/firstName;,
>>   "type" : "string"
>> },
>> *"nullable" : "false"*,
>> "phone" : {
>>   "id" : "http://wso2jsonschema.org/phone;,
>>   "type" : "array",
>>   "items" : [ {
>> "attributes" : {
>>   "primary" : {
>>* "nullable" : "false"*,
>> "id" : "http://wso2jsonschema.org/phone/0/primary;,
>> "type" : "boolean"
>>   }
>> },
>> "id" : "http://wso2jsonschema.org/phone/0;,
>> "type" : "object",
>> "value" : {
>>   "type" : "number"
>> },
>> "properties" : {
>>   "ext" : {
>>* "nullable" : "false",*
>> "id" : "http://wso2jsonschema.org/phone/0/ext;,
>> "type" : "number"
>>   }
>> }
>>   } ]
>> }
>>   },
>>   "namespaces" : [ {
>> "prefix" : "h",
>> "url" : "http://www.w3.org/TR/html4/;
>>   } ]
>> }
>>
>> Then, user can right click on the node and click on 'Enable Nullable' and
>> make the object or array or element, etc nullable.
>>
>>
>> ​The schema will be as follows
>>
>> {
>>   "$schema" : "http://json-schema.org/draft-04/schema#;,
>>  * "nullable" : "true",*
>>   "id" : "http://wso2jsonschema.org;,
>>   "title" : "h:person",
>>   "type" : "object",
>>   "properties" : {
>> "firstName" : {
>>   "nullable" : "false",
>>   "id" : "http://wso2jsonschema.org/firstName;,
>>   "type" : "string"
>> },
>> "nullable" : "false",
>> "phone" : {
>>   "id" : "http://wso2jsonschema.org/phone;,
>>   "type" : "array",
>>   "items" : [ {
>> "attributes" : {
>>   "primary" : {
>> "nullable" : "false",
>> "id" : "http://wso2jsonschema.org/phone/0/primary;,
>> "type" : "boolean"
>>   }
>> },
>> "id" : "http://wso2jsonschema.org/phone/0;,
>> "type" : "object",
>> "value" : {
>>   "type" : "number"
>> },
>> "properties" : {
>>   "ext" : {
>> "nullable" : "false",
>> "id" : "http://wso2jsonschema.org/phone/0/ext;,
>> "type" : "number"
>>   }
>> }
>>   } ]
>> }
>>   },
>>   "namespaces" : [ {
>> "prefix" : "h",
>> "url" : "http://www.w3.org/TR/html4/;
>>   } ]
>> }
>>
>> If a user wants to disable it then, user can right click on the node and
>> click on 'Disable Nullable'
>>
>>
>> ​
>> After enabling, we thought of changing the icon of the tree node so that
>> user can easily identify whether a particular node is a nullable or not.
>>
>> Thanks,
>> Sohani
>> Sohani Weerasinghe
>> Senior Software Engineer
>> WSO2, Inc: http://wso2.com
>>
>> Mobile  : +94 716439774
>> Blog :http://christinetechtips.blogspot.com/
>> Twitter  : https://twitter.com/hanichristine
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Technical Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
> 
> https://store.wso2.com/store/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it