Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: cabbb91360
Fetching contributors…

Cannot retrieve contributors at this time

117 lines (70 sloc) 3.557 kb
** 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
** 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
* 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
** 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?
Jump to Line
Something went wrong with that request. Please try again.