@ -1485,6 +1485,19 @@ thanks to the simple authentication flow. Replacing these services in a Nette
application is also straightforward, thanks to its dependency injection
container implementation.
@todo: what files are stored in api, why there are duplicates among api and fileserver
#### Uploading files
There are two cases when users need to upload files using the API – submitting
solutions to an assignment and creating a new exercise. In both of these cases,
the final destination of the files is the fileserver.
However, the fileserver is not publicly accessible, so the files have to be
uploaded through the API.
@todo permission handling, roles, etc.
#### Solution loading
When a solution evaluation on backend is finished, results are saved to
@ -1515,10 +1528,6 @@ From a short time distance it seems that immediate loading of all jobs could
simplify loading code and has no major drawbacks. In the next version of ReCodEx
we will rethink this decission.
@todo: what files are stored in api, why there are duplicates among api and fileserver
@todo permission handling, roles, etc.
#### Backend management
Considering the fact that we have backend as a separate component which has no
@ -1553,8 +1562,25 @@ enough to implement in low-level backend components. That also means this
feature is visible and can be exploited but from our points of view it seems as
appropriate compromise in simplicity.
@todo: where is stored which workers can be used by supervisors and which runtimes are available, describe possibilities and why is not implemented automatic solution
Next thing relating backend management is storing its current state. This namely
concerns which workers are available for processing with what hardware and which
languages can be used in exercises. Another step is overall backend state like
how many jobs were processed on some particular worker, workload of broker and
workers, etc. The easiest solution is to manage these information by hand, every
instance of API has to have administrator which would have to fill them. This of
course includes only currently available workers and runtime environments,
backend statistics cannot be provided this way.
Better solution is to let these information update automatically. This can be
done two ways either it can be provided by backend on-demand if API needs them
or backend will send these information periodically to API. Things like
currently available workers or environments are better to be really up-to-date
so this can provided on-demand if needed. Backend statistics are not necessary
stuff which can be updated periodically. But it really depends on the period of
updates, if it is short enough then even available workers, etc. could be
updated this way and be quite up-to-date. However due to lack of time automatic
refreshing of backend state will not be implemented in early versions but might
Petr Stefan
8 years ago