TODO.txt

** Database

* LOW: it may be interesting to keep in the Contest not only the last
  scoring snapshot, but a snapshot for each moments in which the
  scorings change.

* LOW: associate to a task also some "test_solutions" that can be
  compiled/evaluated to ensure that the proposed solutions score
  exactly as they are supposed to.

* LOW: decide what to do with ranking views (actually used only for
  SpoolExport). If we want to keep it, we at least need to change the
  indexing from task.num to something more sane, like task.id.



** Worker

* LOW: kill the worker thread when the main thread receives a signal
  to exit (Ctrl-C or from RS). Now the other thread stays alive.

* LOW: should be able to work with 32 bits programs even when running in
  64 bits mode.
  - This actually appears to be quite complicated: it is probably
    easier and more secure to just ask that everything must be made
    with the same number of bits; at the moment it is assumed that
    everything works at 32 bits. I have a 64 bits system and keep
    the Worker inside a 32 bits chroot.



** Task/Score types

* HIGH: double-check communication type for mistakes.

* LOW: ease the creation of new types.



** ContestWebServer

* MED: concurrency: if there are more than 1 CWS, there is a (very
  slight) chance that features such as - but not limited to - "partial
  submission filler" and "avoid frequent submissions" will not work as
  expected. (This may be fixed using ip_hash in nginx.)

* LOW: think at giving CWS some caching capabilities w.r.t. to the
  database. Currently there are several queries per page load, even if
  the data is (supposedly) stable during the contest (start/stop
  times, ...) or the data hasn't change since last page view
  (submissions, ...).

* LOW: allow signup via CWS (that asks for storing hashed passwords
  instead of plain text...)

* LOW: some idea to improve the Web interface:
  - Ability to backup files.
  - Ability to talk with Emacs psychologist, in case of a particularly
    difficult contest.



** AdminWebServer

* MED: give possibility to see the output of an evaluation (storing
  them in the FS? cirumventing the yet-to-be-born TEST facility?).

* LOW: when updating/adding contests, users, and so on, make RWS
  delete the old data (when necessary).

* LOW: auto updating submission statuses.

* LOW: see old data about resource usage (i.e., longer graphs on
  demand).

* LOW: facility for mass-importing users data (reading a list with
  names, generating/printing/sending by email passwords, creating IP
  association, ...)

* LOW: change color of textboxes we changed but not saved in the
  DB. Ask before leaving the page if we are sure to discard our
  changes.



** YamlImporter

* LOW: provide facilities to translate the task's statement.

* LOW: provide an environment to build tasks better than make_Makefile
  and friends.



** File{Storage,Cacher}

* LOW: add support to optionally check file digests when trasferring
  them, both on client and on server side. Moreover, add an API call
  to ask the server to verify some file's digest.



** Misc

* HIGH: always refer to tasks, testcases and such by id instead of num
  (as it is for everything else).

* MED: RunC interface.

* MED: implement the TEST facility mentioned in IOI rules (i.e., the
  user send a source and an input file and the system evaluates it and
  gives back the result). This might be useful also for admins ("CMS,
  please give me the output of submission X on testcase Y").

* LOW: implement task versioning?