Hi Dinuka, my comments are below: > On Apr 4, 2020, at 10:31 AM, Dinuka Desilva <[email protected]> wrote: > > 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. >
The need is to be able to run some applications on the user's desktop. There's a lot more to say about this, maybe Suresh can chime in. > 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. > The airavata-django-portal manages new user accounts and the portal admin adds new users to groups to grant them privileges. Initially, I think this electron client wouldn't have user management or admin capabilities. > 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. > We might be able to put the conditional code in the services layer where it either calls the airavata-django-portal locally or it makes an external call to the Airavata API (or the hosted airavata-django-portal REST API). [1] > 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. > Very good question. There are a couple answers to this, first is the airavata-file-manager service to get SFTP access to user storage on a remote server. The other answer, which Dimuthu could say more about, would be based on the MFT service. Essentially the desktop client needs to upload input files to user's storage and download from user's storage using one of these mechanisms. > 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. > This would be a good thing to explore. A couple of other ideas: a desktop Electron app could use the airavata-django-portal REST API. Also, we've done some experiments with gRPC which should be easier to work with from JS than Thrift, but I don't know the timing of that work. > 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. > > Thanks, Marcus [1] https://github.com/apache/airavata-django-portal/blob/master/django_airavata/apps/api/static/django_airavata_api/js/services/ServiceFactory.js <https://github.com/apache/airavata-django-portal/blob/master/django_airavata/apps/api/static/django_airavata_api/js/services/ServiceFactory.js>
smime.p7s
Description: S/MIME cryptographic signature
