Hi, I started to scaffold a repo. As the first thing, an electron project was created with vue.js. And added some script etc.
https://github.com/dinukadesilva/airavat-electron Regards, Dinuka On Sun, Apr 5, 2020 at 7:19 PM Dinuka Desilva <[email protected]> wrote: > > > 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 >> >> >>
