Requests for Comments

This page is meant as a temporary collection of documentation content still to discuss. The primary idea is to keep the discussion out of the wiki pages and to prevent edit wars. Please extend the page whenever an item pops up and keep discussions on this page. When an item has been resolved, it should be removed.

General

Licence

What licence should be used for JUMMP source code? It seems that the EBI uses GPLv2+. GPL has the disadvantage that all code has to be licensed under the GPL, including external plugins. GPL is not really suited for web applications and not suited for Java development (Classpath exception). Maybe Affero GPL is a better choice. If we want to allow plugins to use a proprietary licence the Apache License might be a better choice. It is not possible to just license the interface with Apache and the core with (A)GPL, as the interface is a derived work of the core. This also has to be considered for web services. An application using the web service could be considered as a derived work of JUMMP!

The converters to be used by JUMMP and developed by the EBI are licensed under the GPL. If JUMMP uses them in the core, the core would be a derived work and would have to be licensed under the GPL. If only plugins use the converters it might be possible to use Apache licence for the core and only the plugin would have to be released under the GPL.

Camille: I agree, the GPL is not well suited for web applications (as anybody can take the code, modify it, provide a service using it and not redistributing the code). The best alternative is the GNU AGPL v3. This would ensure that anybody publicly providing a service using a modified version of the Jummp code, also provides the modified code (which is what the GPL is initially meant for). However, that would not prevent an institution to develop its own modified version and run it internally, without redistributing anything.

Concerning the plugins, they will be very tight to the Jummp infrastructure and therefore could not be re-usable without (big modifications) in another application. I therefore don't see any limitation when using a restrictive license, such as the GPL or AGPL. Anyway, if we were to choose the AGPL (or the GPL), the whole source code would need to be under the same license.

"An application using the web service could be considered as a derived work of JUMMP": this is not true. An application using a library we provide to access the Jummp WS would be considered a derivative work of the library (although, it still depends on which license is used, for the GPL, it is true). Therefore, for such a library I would suggest the LGPL. This would allow third parties to use our library (without modifying it) in their own tools without impacting their license.

Finally, why would we want to allow plugins to use a proprietary licence?

Concerning the GNU AGPL v3, it is compatible with the GNU GPL v3, in the sense that GPL v2+ ("either version 2 of the License, or (at your option) any later version") and v3 components can be included in a AGPL v3 software. However, there might be some issues with GPL v2 only software. For example, the MySQL Connector/J is under GPL v2 only. They do have a FOSS License Exception which allow to use this driver in open software not using GPL; however, in the list of FLOSS licenses they allow, they do not mention the AGPL... I've contacted MySQL in order to have more information about that and their answer is simple: AGPL is not in the list, so we cannot use it (at least for the parts that interact with the MySQL driver).

The current solution is to use GPL v3 for the core and AGPL for the view.

For more information about GNU licenses compatibility, please refer to this table.

For more information about non GNU licenses and GNU licenses compatibility, please refer to this page. Moreover, you might be interested into the diagram provided on this page, which explains the link between various GNU and non GNU licences.

A thread on this topic has been started on jummp-discuss.

IRC

The IRC channel "#jummp" has been registered on freenode for collaborative development.

CIA.vc

Do we want and need integration to CIA.vc? It is a tracker of all commits to all open-source projects. CIA.vc offers useful features like IRC bots sending commits into the team channel.

Package Structure

What should be the package structure for JUMMP?

Proposal: * net.biomodels.jummp.core as base for everything that goes into the core * net.biomodels.jummp.plugins as base for all plugins

Camille: it would probably be better to not put "biomodels.net" there, however, we don't want "jummp.org" either...

i18n

Does JUMMP need i18n and if yes how should it be done? A good solution might be to use gettext.

Camille: that is definitively a good idea if that does not need to much work to implement.

Customisation

Making the text in the UI configurable might be useful for different instances (e.g. DKFZ calls instance JUMMP, EBI calls it BioModels Database).

Camille: I completely agree, various elements of the UI should be configurable.

• icon
• title
• all links should be relative
• CSS
• several (all?) static content (contact, terms of use, ), with the main exception of the help
• ...

Note: I would not call an instance with the same name as the software, mainly to avoid confusion.

Development Conventions

Coding Style

For indentation K&R style is proposed. This would require the braces to go in an own line of code. I doubt that this increases readability for the following reason: Groovy closures. Closures are often used as a replacement for methods and are assigned to variables. Consider the following code fragment from a controller: {{{ def action = { render(view: "foo") } }}}

With K&R style this would look like: {{{ def action = { render(view: "foo") } }}}

The correct indentation style is mostly very subjective and nobody is "right". But having the right hand side of an assignment on a new line, just looks wrong.

Given that all documentation to Grails uses the Java indentation this style change is a hard burden for new contributors.

Camille: could we use that indentation style only for closures?

Requirements

Uploading a Model

The requirement has been modified to allow the submission of models without being logged in. In case the user is not logged in, the group of curators should become the owner of the model. The rational for this requirement is that scientists don't want to log in, they just need to upload the model for a publication. This is in fact a special requirement and should not be bundled with the normal uploading a model requirement. KISS

Problems with this approach: * It complicates the logic: feature should only be available if there is a group of curators, a curation plugin loaded and so on. That means the core would have to adjust itself towards one plugin. This is bad design. * It changes the general security approach: instead of a user a group of users becomes the owner * There is the risk that a user accidentally uploads the model directly to the curators instead of the private branch * This requirement is specific to the EBI, therefore should go into a plugin

Questions: * Would it be acceptable to require a user account? Rationale: Most systems require to have a user account for using their services and during not-logged-in submission almost the same information has to be entered anyway * Could the problem be solved by using services like OpenID? Rationale: most people have an openid account (e.g. gmail address). * Could the problem be solved by creating an account implicitly? This would require the submitter to enter a username and password, but in return he would be able to view the model * Could the problem be solved by creating a locked account in the background? This would allow to not change the normal logic: the owner is a user and the curation process is started in the normal way.

Camille: we may be able to require a user account (if it is very quick, easy to setup and provide the user with some advantages). But we should have an option at submission "directly transfer to curation". Otherwise, users would need to create an account, login, upload the model, add info about the model, and finally transfer it to curation. That's a long process...

Concerning "it changes the general security approach: instead of a user a group of users becomes the owner": we do still need to be able to manage groups of users anyway.

I don't understand the "locked account in the background".

Creating the Model

Is storing of original filename needed? Rationale: it does not hurt to store it and might be handy (users could search for it).

Camille: does that mean we need to specifically ask the user a name for his/her model? The submission will become quite tedious... In other hand, if the name is in the model, we can always retrieve it.

Publications

Camille: What is Type?

Uploading a Model Revision

TODO: would worth to explain a bit more the access to previous revisions here...

Use Cases

Administrator

Usage statistics about anonymous users can rely on an external infrastructure (firewall of the institute). However, the system should be able to log any activities performed by logged users. The level of logging should be customisable.

approve-account-creation

Why is it required that an administrator has to confirm the account creation? This seems like an unnecessary manual step causing delay for new users. If the user confirms an mail reception should really be enough. In case the EBI needs such a functionality it should go into a plugin.

Camille: if we have a fairly robust protection when creating an account (Captcha or other) in order to avoid spam (in the sense of spam submission), I believe we might not need such confirmation.

Features

Secondary accession numbers

A feature we did not mentioned so far but need to be thought about: handling of models having several identifiers. The case can occur when initially several models were submitted (and publication -in the non-curated branch-) and after some curation work, it happen that one model is enough.

We need to be able to access the unique curated model from all identifiers and be able to retrieve older revisions of the other models.

public VS private

There is a notion that I probably not emphasised so far: the notion of public, which is different than the notion of published.

By "private" I mean all models which can only be accessed by their owners and collaborators.

By "public" I mean all models which will definitively be published (already or at some point in the future). This includes models in the curation process and of course published models.

This distinction is important because some searches should be able to look into all public models. For example, if a user has the identifier of a model which is not published yet (because the associated publication is under review), he/she should be able to retrieve some information about it (basically that the model exists and its current state).

Contextual help

We should have a little help icon which gives access to some information and help about the feature/page currently viewed by the user.

The whole set of help pages could also be browsable independently and be (part of) the user documentation.

Security

Be able to provide all pages via HTTPS.