On Sat, Apr 4, 2020 at 8:01 PM Dinuka Desilva <[email protected]> wrote:
> Dear community, > > I would like to start of a discussion on this epic with few questions. > Please engage. > > *1) Purpose of airavata-django-portal* > I see it's an interface for airavata service. So, that it's accessible > from a browser for authenticated users with authorised privileges. So, this > is more similar to phpMyAdmin for mysql. For any airavata service, this can > be exposed as an admin portal. In addition to that, airavata-django-portal > let the users manage a storage and use them on experiments. > > *2) Why do we need a desktop application for airavata?* > More than this being just another copy of airavat-django-portal available > as a desktop application, I believe this could be kind of a mysql-workbench > for mysql where multiple connections can be managed together. So, that who > ever has the connection details to a airavata service could make a > connection and get the needful done. But, then I get following questions. > > *2.1) What's the existing way of managing users?* > I can see anybody could signup. But, I couldn't find where the user > privileges can be managed? Should we include kind of a section on the > desktop application or should we encourage the desktop application only to > users who has credentials to a airavata service. > After going through the airavata-django-portal and confluence docs, It could be figured out that the authentication and authorization layer is external to the airavata api [1] and it defers them to the gateways. I also could see that the portal maintains tables for permissions and credentials. But, still I couldn't find any UI component to manage the permissions or users. Is it only at the db layer yet? Reference [1], I feel it could have been better if there's atleast some kind of a gate for the api endpoints by default. Consequently, for the desktop application. a gateway has to be used instead of the airavata apis directly . Then, the desktop application is pretty much similar to the airavata-django-portal except in the way of using storage. Is that the only purpose of desktop application? > > *2.2) Reusing components from airavata-django-portal* > Yes, it can be done. But, since it's plugged to it's own endpoints instead > to airavata services directly, if we are doing what's on (2), It'll be > required to put in so many conditional code inside components which would > be too much configurations. But, still we could refactor some of them to > view only components and reuse. So, that it'll be easy to upgrade. Given it > could be not if the UX is changed based on what's expected in the desktop > application. > > *2.3) User storage management* > For the desktop application, Do we need to manage a separate user storage. > We could let it use the computer storage instead. > > *2.4) Airavata javascript api client * > I can see this is going to be a common component generated using the > airavata thift api spec. Since, it's a reusable component for many cases, > would it be a good idea putting that as a package on npm. So, it'll be not > duplicated. > > *2.5) Additional functionalities* > Other than the functions available on airavata-django-portal and few > mentioned above, Do you have anything on you mind which could be included > on a desktop application particular. > 2.6) API gateway implementation I can see many gateway implementations. But, different designs. On an additional note, I see that these could make use of an api manager [2] instead. And authentication and authorization providers [3] instead redundant implementations. *References* [1] https://cwiki.apache.org/confluence/display/AIRAVATA/Airavata+API+Overview [2] https://wso2.com/api-management/ [3] https://wso2.com/identity-and-access-management > Regards, > Dinuka > > >
