My idea was different, "Can anyone point me any site/forum which allow you
to edit others comment(*not* approve/reject or *delete entire comment*)".
Delete entire comment support need to be their definitely. No doubt about
that.

Thanks,
sanjeewa.

On Fri, May 19, 2017 at 12:01 PM, Fazlan Nazeem <fazl...@wso2.com> wrote:

> Hi Sanjeewa,
>
> In facebook, if someone posts a comment on our post, then we have the
> permission to delete that comment even though that comment was not created
> by us.
>
> In a similar manner, shouldn't we at least support delete comment
> permission to a moderator role(api owner or a configurable moderator role)?
>
> On Fri, May 19, 2017 at 11:22 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> Can anyone point me any site/forum which allow you to edit others
>> comment(not approve/reject or delete entire comment). I'm just curious :)
>> Think what will happen when someone comment on your blogs, media etc(or
>> even you can think of product comments of most common e commerce
>> platforms).  It will go through approval process or filter and then publish.
>>
>> If we allow someone to edit others comments its a crime IMO :). Hence -1
>> for let someone to edit/update others comment.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>
>>
>> On Fri, May 19, 2017 at 11:04 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> I think standard forums allow privileged users to moderate comments.
>>> Moderation can be in the form of approving/rejecting comments or in the
>>> form of removing obscene type of comments.
>>>
>>> If we go down the workflow (approval) path, there's much to implement.
>>> Ex: We need to introduce a "state" to the comment, need to implement a
>>> workflow, a callback mechanism, a workflow cleanup, etc. But if we just
>>> write a piece of code which allows a pre-configured role to remove, edit
>>> comments, I think the implementation is much simpler.
>>>
>>> On Fri, May 19, 2017 at 10:52 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 19, 2017 at 10:43 AM, Bhathiya Jayasekara <
>>>> bhath...@wso2.com> wrote:
>>>>
>>>>> Hi Sanjeewa,
>>>>>
>>>>> On Thu, May 18, 2017 at 5:09 PM, Sanjeewa Malalgoda <sanje...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> I don't think its worth to get complete permission model for comments
>>>>>> as well. Like bhathiya mentioned only comment owner is allowed to
>>>>>> update/delete his comment. That is the normal behavior. Also i feel its
>>>>>> better if we can have work flow support for comments(by default this need
>>>>>> to disabled). Once something posted if we let someone else to modify its
>>>>>> not nice.
>>>>>>
>>>>>
>>>>> Admin or similar role might be needing moderator capability for
>>>>> comments. WDYT? To support that we can easily use existing permission
>>>>> model.
>>>>>
>>>> I haven't see a single website or forum which allows one person to edit
>>>> others comments. We cannot edit or update any others comment :) Its not
>>>> Only thing admin or other person can do is approve/reject comment or delete
>>>> it. It means workflow + delete permission to only super user. WDYT?
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>
>>>>> Thanks,
>>>>> Bhathiya
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> sanjeewa.
>>>>>>
>>>>>> On Thu, May 18, 2017 at 11:20 AM, Fazlan Nazeem <fazl...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Nuwan/Bhathiya,
>>>>>>>
>>>>>>> On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>>>
>>>>>>>> I think what Bhathiya is suggesting is to bring in our usual
>>>>>>>> permissions model (in APIM 3.0.0) to comments as well. This will 
>>>>>>>> require
>>>>>>>> more data to be saved in the DB but will address the issue at hand.
>>>>>>>>
>>>>>>>>
>>>>>>> Are you suggesting we should have an extra column in Comments table
>>>>>>> in the db to fulfill this?
>>>>>>>
>>>>>>> I am thinking of using the AM_API_PERMISSION column introduced in
>>>>>>> AM_API table to decide on who can update/delete a specific comment. 
>>>>>>> Apart
>>>>>>> from the user who commented, If a user can delete or update an API he 
>>>>>>> can
>>>>>>> delete/update any comment for that API. This way we do not need to save
>>>>>>> extra information in the db, and can use the api permission information 
>>>>>>> to
>>>>>>> control the comment actions.
>>>>>>>
>>>>>>> There are two levels of permissions required here. One is "who can
>>>>>>>> add/update/remove comments in general" and the other is "whose 
>>>>>>>> comments can
>>>>>>>> I update/remove".
>>>>>>>>
>>>>>>>> The first can be simply achieved using scopes. Basically say which
>>>>>>>> scope is permitted for the /comments API. The second can be solved by 
>>>>>>>> using
>>>>>>>> our usual permission model in APIM v3.0.0.
>>>>>>>>
>>>>>>>> On Tue, May 9, 2017 at 10:10 AM, Ayyoob Hamza <ayy...@wso2.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This won't tackle the problem Musthaq suggested which requires
>>>>>>>>> validation in the backend.
>>>>>>>>>
>>>>>>>>> *Ayyoob Hamza*
>>>>>>>>> *Senior Software Engineer*
>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>>>>>>>>
>>>>>>>>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <ayy...@wso2.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We had a similar requirement to have a fine grained access for
>>>>>>>>>> users in IoTS and we went with the approach of assigning permission 
>>>>>>>>>> for
>>>>>>>>>> scope rather than roles.
>>>>>>>>>>
>>>>>>>>>> *Ayyoob Hamza*
>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>> email: ayy...@wso2.com cell: +94 77 1681010
>>>>>>>>>> <%2B94%2077%207779495>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <musht...@wso2.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Prasanna/Pubudu,
>>>>>>>>>>>
>>>>>>>>>>> I think if we use scope based validation there will be an issue
>>>>>>>>>>> here. Lets take the same example.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *GET /apis/{apiId}/comments/{commentId}              -
>>>>>>>>>>>  comment-add-scopeDELETE /apis/{apiId}/documents/{documentId}      -
>>>>>>>>>>>  comment-delete-scopeUPDATE /apis/{apiId}/documents/{documentId}    
>>>>>>>>>>>   -
>>>>>>>>>>>  comment-update-scope*
>>>>>>>>>>>
>>>>>>>>>>> Scope and roles matching are as follows.
>>>>>>>>>>>
>>>>>>>>>>> *comment-add-scope : subscriber-role, **admin-role*
>>>>>>>>>>> *comment-**update**-scope :  **subscriber-role, **admin-role*
>>>>>>>>>>> *comment-delete-scope : **admin-role*
>>>>>>>>>>>
>>>>>>>>>>> Lets say there are two store users *A* and *B* who have the 
>>>>>>>>>>> *subscriber-role.
>>>>>>>>>>> *And user *A* adds a comment to an API (*comment-add-scope*).
>>>>>>>>>>> Then user *B *logs in and he will be able to update that
>>>>>>>>>>> particular comment which user *A *has added since user *B *has
>>>>>>>>>>> the *subscriber-role* too.
>>>>>>>>>>>
>>>>>>>>>>> IMO this should not be allowed. AFAIC we might have to go with
>>>>>>>>>>> user validation.
>>>>>>>>>>> If we can get the logged in user's roles and if that user has
>>>>>>>>>>> admin-role or that particular comment is added by the logged in 
>>>>>>>>>>> user we can
>>>>>>>>>>> allow this user to update or delete the comment. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Mushthaq
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 9, 2017 at 6:31 AM, Prasanna Dangalla <
>>>>>>>>>>> prasa...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Fazlan,
>>>>>>>>>>>>
>>>>>>>>>>>> I think as Ishara and Pubudu have mentioned we can use the
>>>>>>>>>>>> scope validation.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 9, 2017 at 12:03 AM, Pubudu Gunatilaka <
>>>>>>>>>>>> pubu...@wso2.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> + Adding architecture mail group
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka <
>>>>>>>>>>>>> pubu...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Fazlan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As Ishara mentioned above, we can do this with scope
>>>>>>>>>>>>>> validation. Each and every resource has a scope. The scope is 
>>>>>>>>>>>>>> associated
>>>>>>>>>>>>>> with one or more roles. Consider the following example.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Resource and scope matching are as follows.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *GET /apis/{apiId}/comments/{commentId}              -
>>>>>>>>>>>>>>  comment-add-scopeDELETE /apis/{apiId}/documents/{documentId}    
>>>>>>>>>>>>>>   -
>>>>>>>>>>>>>>  comment-manage-scopeUPDATE /apis/{apiId}/documents/{documentId} 
>>>>>>>>>>>>>>      -
>>>>>>>>>>>>>>  comment-manage-scope*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Scope and roles matching are as follows.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *comment-add-scope : subscriber-role, **admin-role*
>>>>>>>>>>>>>> *comment-manage-scope :  admin-role*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> @Pubudu:
>>>>>>>>>>>>
>>>>>>>>>>>> IMO a person who adds a comment should have the UPDATE
>>>>>>>>>>>> privilege as well. DELETE can be restricted to admin. Like wise we 
>>>>>>>>>>>> might
>>>>>>>>>>>> find many combinations with different use cases. So I think its 
>>>>>>>>>>>> better to
>>>>>>>>>>>> decouple this  *comment-manage-scope *to two different scopes
>>>>>>>>>>>> as
>>>>>>>>>>>> *comment-update-scope *and *comment-delete-scope. *If we do
>>>>>>>>>>>> this, we can assign it to respective roles in scope and role 
>>>>>>>>>>>> mapping for
>>>>>>>>>>>> different use cases.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Prasanna
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When a user hits the GET resource we can do the following.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Retrieve the scope of the resource
>>>>>>>>>>>>>> 2. Retrieve the roles of the scope
>>>>>>>>>>>>>> 3. Validate the user based on the role and allow or deny the
>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, May 8, 2017 at 5:04 PM, Fazlan Nazeem <
>>>>>>>>>>>>>> fazl...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray <
>>>>>>>>>>>>>>> isha...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How about introducing scope based permission model?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can define scope for each resource and validate against
>>>>>>>>>>>>>>>> the logged in user scopes.
>>>>>>>>>>>>>>>> This way we can let the admin to edit the scope so that he
>>>>>>>>>>>>>>>> can fine grain the access to these resources.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My understanding is, with scopes what we can decide is
>>>>>>>>>>>>>>> whether a particular user has access to hit an API resource 
>>>>>>>>>>>>>>> URL. In my
>>>>>>>>>>>>>>> example all users with subscriber scope will have access to hit 
>>>>>>>>>>>>>>> the api,
>>>>>>>>>>>>>>> but the question is, out of those subscribers how do we choose 
>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>> subscriber for the right action.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>> Ishara Cooray
>>>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512>
>>>>>>>>>>>>>>>> WSO2, Inc. | http://wso2.com/
>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:42 PM, Fazlan Nazeem <
>>>>>>>>>>>>>>>> fazl...@wso2.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is about how we should handle access permission for
>>>>>>>>>>>>>>>>> subresources in api store.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Parent Resource Access *
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Consider the following REST calls.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> GET /apis/{apiId}/comments/{commentId}
>>>>>>>>>>>>>>>>> GET apis/{apiId}/documents/{documentId}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At the moment we are not checking whether a particular
>>>>>>>>>>>>>>>>> user has read access to the specific api before we retrieve 
>>>>>>>>>>>>>>>>> the requested
>>>>>>>>>>>>>>>>> comment or document. Is it fine to ignore this check for 
>>>>>>>>>>>>>>>>> these apis
>>>>>>>>>>>>>>>>> assuming that a user might be already having read access to 
>>>>>>>>>>>>>>>>> the api because
>>>>>>>>>>>>>>>>> he already knows the uuid of the api?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or should we be doing an explicit permission validation?
>>>>>>>>>>>>>>>>> Do we have any drawbacks in doing this check?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Subresource Update/Delete*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Consider the following REST api calls done by a user in
>>>>>>>>>>>>>>>>> store.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> DELETE /apis/{apiId}/comments/{commentId}
>>>>>>>>>>>>>>>>> UPDATE /apis/{apiId}/comments/{commentId}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> DELETE /apis/{apiId}/documents/{documentId}
>>>>>>>>>>>>>>>>> UPDATE /apis/{apiId}/documents/{documentId}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In order to restrict who can update and delete these
>>>>>>>>>>>>>>>>> subresources, we can pass the username to DAO layer and check 
>>>>>>>>>>>>>>>>> who created
>>>>>>>>>>>>>>>>> it, and allow only that person to do these modifications. But 
>>>>>>>>>>>>>>>>> there could
>>>>>>>>>>>>>>>>> be a use-case where another user(admin) will need to delete 
>>>>>>>>>>>>>>>>> or update a
>>>>>>>>>>>>>>>>> resource created by someone else. If we restrict only the 
>>>>>>>>>>>>>>>>> creator to do
>>>>>>>>>>>>>>>>> these actions, then we cannot support such a use-case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Appreciate your thoughts on this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Fazlan Nazeem
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *WSO2 Inc*
>>>>>>>>>>>>>>>>> Mobile : +94772338839
>>>>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194>
>>>>>>>>>>>>>>>>> fazl...@wso2.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Fazlan Nazeem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *WSO2 Inc*
>>>>>>>>>>>>>>> Mobile : +94772338839
>>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194>
>>>>>>>>>>>>>>> fazl...@wso2.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Pubudu Gunatilaka*
>>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos
>>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>>>>>>>> mobile : +94774078049 <%2B94772207163>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Pubudu Gunatilaka*
>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos
>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>>>>>>> mobile : +94774078049 <%2B94772207163>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mushthaq Rumy
>>>>>>>>>>> *Software Engineer*
>>>>>>>>>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
>>>>>>>>>>> Email : musht...@wso2.com
>>>>>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>>>>>> lean . enterprise . middleware.
>>>>>>>>>>>
>>>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nuwan Dias
>>>>>>>>
>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>>>>> email : nuw...@wso2.com
>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Architecture mailing list
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards,
>>>>>>>
>>>>>>> Fazlan Nazeem
>>>>>>>
>>>>>>> *Senior Software Engineer*
>>>>>>>
>>>>>>> *WSO2 Inc*
>>>>>>> Mobile : +94772338839
>>>>>>> <%2B94%20%280%29%20773%20451194>
>>>>>>> fazl...@wso2.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Sanjeewa Malalgoda*
>>>>>> WSO2 Inc.
>>>>>> Mobile : +94713068779 <071%20306%208779>
>>>>>>
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Bhathiya Jayasekara*
>>>>> *Associate Technical Lead,*
>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>
>>>>> *Phone: +94715478185 <071%20547%208185>*
>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>> <https://twitter.com/bhathiyax>*
>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Sanjeewa Malalgoda*
>>>> WSO2 Inc.
>>>> Mobile : +94713068779 <+94%2071%20306%208779>
>>>>
>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <077%20777%205729>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
>
> Fazlan Nazeem
>
> *Senior Software Engineer*
>
> *WSO2 Inc*
> Mobile : +94772338839
> <%2B94%20%280%29%20773%20451194>
> fazl...@wso2.com
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

<http://sanjeewamalalgoda.blogspot.com/>blog
:http://sanjeewamalalgoda.blogspot.com/
<http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to