[contestms-dev] Re: Separate users and tasks from contests
- From: William Di Luigi <williamdiluigi@xxxxxxxxx>
- To: contestms-dev@xxxxxxxxxxxxx
- Date: Tue, 12 Aug 2014 14:48:50 +0200
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:
