[contestms-dev] Re: Separate users and tasks from contests
- From: William Di Luigi <williamdiluigi@xxxxxxxxx>
- To: contestms-dev@xxxxxxxxxxxxx
- Date: Tue, 12 Aug 2014 17:25:15 +0200
On Tue, Aug 12, 2014 at 3:33 PM, Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
wrote:
> Re PWS: yes, it's kind of heavy, so I prefer if it continues to live as a
> separate project - but it is useful to know that it is around, if we are
> going to need some of its features we can borrow instead than starting from
> scratch (the first might be the privileged users for using various parts of
> AWS).
>
Or, if we eventually set up a plugin system for CMS, I think it would be
possible to make PWS become a plugin.
> Re the main point: I think that Giovanni has a few very good points
> against treating tasks out of contests in the same way as users out of
> contests. I agree with him that it would be surprising to see a task in a
> contest being modified after I modify a task for a different contest (which
> is what would happen if the underlying task was a single object). Also I
> think that the division of fields between Task and TaskContest is always
> going to be a bit arbitrary.
>
I think that if a task is changed, that's because it had errors (wrong
statement, wrong jury's solution...), so it makes sense if it gets updated
automatically across all contests which use it (see the example I talked
about in the last mail).
> What about Giovanni's half-idea of cloning tasks? You would still have (as
> in your idea) a task repository inside CMS (no need to import stuff from
> outside for your privileged users), and each occurrence of a task in a
> contest is still going to be separate from all other instances. We can have
> an additional "parent" field for tasks, marking the one from which they
> come from, and we can have an interface to see diff of configuration and
> easily sync them.
>
> This would be good also for datasets, honestly :)
>
If I understand correctly, you are proposing to implement a task versioning
system. I'm not sure, but I think *that* would be one hard thing to do :)
By the way, I, Gabriele Farina and Luca Versari are working on a new format
(derived from italy_yaml) which aims to implement task versioning (a task
can "extends" from multiple tasks) at higher level (that is, before
importing the task to the DB), for example: "mytask/" folder contains the
default task, "mytask_grader/" extends "mytask/" but applies changes to
make it become a task with graders. Now let's say we increase the limit for
N from N <= 1000 to N <= 1000000, so we create a new task "mytask_hard/"
which extends from "mytask/", but, if we want to, we can also extend from
"mytask_grader/" in order to have a harder task with graders.
Thus, the current idea was to hide task versioning from CMS. We will have
*cms-make* support it, and when it will "make" everything needed, CMS will
import the task. So, taking that example again, we can (cms-)make "mytask",
then import it, then (cms-)make "mytask_harder_grader", import it, and
we'll have two different tasks imported (CMS will think that they are
entirely different tasks, but one of them was instead derived from the
other one).
We are working on it (design phase) here:
https://docs.google.com/document/d/1sCciUTjIZntJVvipw1G2kIP-I22K6yMVrkpeLrvqi_U/edit?usp=sharing
(*now* in english, thanks to Gabriele for helping with the translation).
--
William.
Other related posts:
