UI for ChRIS store

[mairin]

Jorge is working on development.

• UI is targeted at developers.
• UI allows developers to register their plugins

@jbernal0019 any other tasks that developers are going to be doing in the ChRIS store? Can you give a little more detail / quick outline of the workflow for them?

[jbernal0019]

Sure.

First the plugin developer needs to create the required plugin representation. there are two ways they can do so:

1- By following the instructions here:

https://github.com/FNNDSC/cookiecutter-chrisapp

In this case we provide them with all the required scaffolding to develop a containerized plugin app that can automatically generate the plugin representation by just running the app with the --savejson option.

2- By creating a free form containerized plugin app (by not following the instructions above)

In this case developers will need to create a JSON file containing the plugin representation by themselves. BTW we need to document this JSON file format but it’s still easy to just generate it from an existing plugin and then adapt it to their application at hand.

Second, in both cases the plugin developer will need to upload a form to the ChRIS store with four required elements:

1. Plugin’s name (string such as ‘simplefsapp’)
2. Plugin’s docker image url/name (string such as ‘fnndsc/pl-simplefsapp’)
3. Plugin’s publi repo (string such as ‘https://github.com/FNNDSC/pl-simplefsapp’)
4. Plugin’s descriptor file (the above JSON file)

The plugin developer will also need to upload a new form like this when he/she wants to modify a plugin representation in the store.

I’m not sure whether we should require #3. Currently it’s required because we are putting emphasis on open source plugin apps.

The ChRIS store UI should also allow users to browse all registered plugins and delete a plugin. Currently the store's API only allows authenticated users to browse plugins in the store. That's something open to debate.

[jbernal0019]

Also we will need to add both to the ChRIS store API and to it's UI some descriptors/labels with the "status" of a plugin. Maybe something like "broken", "time-consuming", etc...

Finally as I mentioned this morning a JavaScript client for the ChRIS store API needs to be developed. I think I will be able to help with that.

[mairin]

@jbernal0019 how were you thinking of implementing the client? E.g. would it be a web app that the user would run locally, a centrally hosted web app, or a client-side app?

[NicolasRannou]

@mairin what is the difference between a centrally hosted web app, or a client-side app? Is your question "is there gonna be a unique store or is everybody gonna be able to run its own store somehow?"?

[mairin]

@NicolasRannou

Well you bring up another good point, if there is a unique store vs different stores to choose from. I think I made an assumption on that point: I think of this in terms of how software repos work in linux - eg in Fedora or Ubuntu there is one main store, but then there are third-party repositories (eg for Fedora, rpmfusion) and user-hosted repos (e.g. PPA for Ubuntu or coprs for Fedora), they can all be plugged into the package system and searched across and installed from.) So I was thinking there might be a central repo with some common plugins, or maybe different institutions would want their own (maybe a 'fork' or 'clone' of the main one) with some modifications or extras bundled in.

For the app question - I guess I was thinking the user here is the ChRIS admin. So if the ChRIS admin is looking to install new plugins on their ChRIS install... is there a panel somewhere in the ChRIS UI itself that they click on, and the browse UI is within their ChRIS install? (that's what I mean by client side even though technically I guess it's not, rather, it's on the individual user / institution's ChRIS installation). Or would they be redirected to some central website like chrisplugins.com or whatever where they could browse the list of plugins (think like maybe the play.google.com store for Android apps) and click "install" and somehow it would redirect to their ChRIS installation to queue the install.

I hope that makes more sense? What do you think?

[mairin]

I thought maybe some diagrams would help explaining the questoin about how the store model would work. @jbernal0019 which one of these (or something else?) is the model you were thinking for the ChRIS store?

[mairin]

I'm going to start sketching out concepts / screen designs to cover the following functions to have something to show by Wed July 27:

• Create/Register Plugin Definition
• Modify Plugin Definition
• View Plugin Definition List
• View Category List
• View Plugin Definition List by Category
• View/Download Plugin Definition
• Delete Plugin Definition

[mairin]

@jbernal0019 I'm assuming that there might be multiple developers adding their plugins to the same store, and that we'd want to set permissions up such that developer A can modify developer A's plugins but not developer B's. I'm also assuming that any developer can view all plugins in the system regardless of whether or not they own them. Does this sound ok?

[jbernal0019]

You're right @mairin The ChRIS store backend already takes care of that. You can try by yourself by following the directions here: https://github.com/FNNDSC/ChRIS_store to get the store service up and running (in dev mode). Then you can make a couple of POST requests to create a couple of user accounts as explained in the section:

An unauthenticated POST request to create a new ChRIS store user account

Then you can upload a plugin definition as one user and then try to modify it as another user. The store won't allow it.

In any case if in the process of developing the UI it is found out that something needs to be changed in the backend then please let us know.

[mairin]

I'm going to creating the mockups with the assumption the store is a centralized single entity (like the setup #2 diagram basically, without acknowledging 3rd party stores. Basically like dockerhub or something like that). If this is assumption is flawed let me know :)

[jbernal0019]

I think that's a reasonable assumption. Different stores will function independently. They can even have the same plugins registered.