SOLID POD: Code separation and refactoring

This is inspired by a discussion with Anushka about when we can assume the authentication tokens are available and how we can simplify existing functions in solidpod.

Suppose we classify the code in solidpod into three levels:

• Top level : The user interface code
• Middle level: Functions called by Top level code, and they call the low level functions
• Low level: Functions interacting with the solid server through REST calls, called by the Middle level code

It seems reasonable to do the following:

• A low level function can assume the authentication (i.e. tokens, webId) already exist (i.e., the user must have logged in), otherwise, throw an exception
• A middle level function (which has access to the build_context of the user interface) should check if the authentication data exist, and use them directly if they are valid, otherwise, request them from the user (e.g. through a pop-up window which requires the build_context)
• A Top level function would be better to just call middle level functions instead of incorporating complex logic (e.g. in the onPressed function of a button).

According to Anushka, (some of) these have already been adopted in the gurriny project. If the above makes sense in the context of solidpod, we will need to refactor its existing codebase.

PS: It is likely the master password used to encrypt data can be treated similarly as the authentication data.

Sub-issues (to be updated over time):

• #116
• #117
• #120