[contestms-dev] Re: Separate users and tasks from contests
- From: Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
- To: contestms-dev <contestms-dev@xxxxxxxxxxxxx>
- Date: Tue, 12 Aug 2014 14:33:20 +0100
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).
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.
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 :)
-- Stefano
On 12 August 2014 13:48, William Di Luigi <williamdiluigi@xxxxxxxxx> wrote:
> On Tue, Aug 12, 2014 at 9:39 AM, Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
> wrote:
>
>> Yes, separating users and contests was a long-standing wanted feature. I
>> don't think there is much advantage for 2-days contests, where we are more
>> or less ok with the RWS model. I wanted this for training settings were you
>> may have many contests and you want to do something for which you need to
>> connect users in different contests, and that is smarter than what RWS does
>> (which is just a sum). I feel that we could do much more for these settings
>> and this goes in the right directions.
>>
>> About tasks, I'm not so sure of the advantages, I have the feeling that
>> your use case is not shared with many people. I'm not even deeply against,
>> if not for the work required.
>>
>
> I think that it wouldn't require a lot more work compared to the
> users-contests separation... Sure, it would have been easier to have it in
> the first place: it's better to foresee possible extensions early on.
>
> However, now that you mention training (i.e. in the italian case: "about a
> week of training, where there will be some selection contests and a
> *permanent* training contest, which is gradually updated with other
> contests' tasks") notice that, in such a case, the "permanent" training
> contest would benefit from the tasks-contests separation, because you would
> have to simply "tie" these new task to the permanent contest, instead of
> reimporting it.
>
>
>> I tried looking at your branch but it was kind of difficult to understand
>> the state, so I have a few questions.
>>
>> - For both users and more importantly for tasks, which fields are
>> dependent on the contest? When I was working on the Italian repo, one
>> observation was that often it doesn't make a lot of sense to reuse the same
>> timeouts for old tasks as new hardware and better compiler make the same
>> program much faster.
>>
>
> For User, these fields would get moved to UserContest:
>
> - password
> - ip
> - starting_time
> - delay_time
> - extra_time
>
> And for tasks, these fields would get moved to TaskContest:
>
> - num (number of the task for sorting)
> - "token_mode"-related fields ...
> - max/min submission/user_test number/interval ...
>
>
> - Are you thinking of porting back your PWS? As I understand it's not
>> under discussion here (and it would require another discussion).
>>
>
> I don't know if cms-dev will ever accept PWS upstream, but we would love
> that :). We are trying to keep our fork constantly rebased on cms/master
> and we designed PWS to be hot-swappable (just like CWS and AWS). It would,
> however, be quite a heavy addition to CMS: it introduces a forum, private
> messages, a privilege system where some users are allowed to do things like
> moderating the forum, (soon) there will be a system to set up tasks (it
> will just be a GUI to cmsMake which, as a side note, we want to rewrite in
> a modular fashion in order to have a "core" cmsMake component, a CLI for
> contest admins and a GUI to be used within PWS [actually it'll be a WUI =
> Web User Interface]). I'm also planning to migrate all our JavaScript to
> Dart <https://www.dartlang.org/>, which simplifies component reuse. If I
> manage to do so, I'd like to migrate also CWS and AWS to Dart (in order to
> share components between all of them).
>
>
>> - What timeframe do you expect to finish all of these changes? Even
>> though I didn't tell anybody yet, I'd like CMS to follow a best-effort
>> semestral release cycle, with heavier stuff going in in the release ending
>> in July, and milder stuff in January. Do you think that this is "mild"
>> enough and would be implemented fast enough to get in in January?
>>
>
> We will use PWS as our project for a DB course at school. We have about
> one month from now to (kind of) complete it.
>
> --
> William.
>
Other related posts:
