Here are some common examples: https://help.github.com/articles/editing-a-comment/ https://en.support.wordpress.com/manage-comments/
Thanks, Bhathiya On Fri, May 19, 2017 at 12:33 PM, Sanjeewa Malalgoda <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected] >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 19, 2017 at 10:43 AM, Bhathiya Jayasekara < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Sanjeewa, >>>>>> >>>>>> On Thu, May 18, 2017 at 5:09 PM, Sanjeewa Malalgoda < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Nuwan/Bhathiya, >>>>>>>> >>>>>>>> On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>>> 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: [email protected] cell: +94 77 1681010 >>>>>>>>>> <%2B94%2077%207779495> >>>>>>>>>> >>>>>>>>>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <[email protected]> >>>>>>>>>> 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: [email protected] cell: +94 77 1681010 >>>>>>>>>>> <%2B94%2077%207779495> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <[email protected] >>>>>>>>>>> > 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> + Adding architecture mail group >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray < >>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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> >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> *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 >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> 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 : [email protected] >>>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>>> >>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : [email protected] >>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> 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> >>>>>>>> [email protected] >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 <077%20777%205729> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> 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> >> [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *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/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
