Clarify/redo design

[nqpz]

There are many layers in the code, and it is not clear to me how they work together.

For example, I'm perpetually confused by the Cachable* Python classes (though I kind of understand their purpose).

Also, when I had to add someone to a group on Absalon the other day, staffeli insisted on first downloading all groups before doing any changes. I suppose the idea here is to always have an up-to-date local copy of the Absalon groups (among other things), but I question whether this is necessary.

[nqpz]

Still, the basic design of having a .staffeli.yml in each directory seems a good one, so we should keep that.

[oleks]

I have often found the .staffeli.yml files useful when the command-line or Python API falls short, so I too would like to keep that part around together with the folder structure, which I think works OK.

I have fallen a bit off the bandwagon here partially because I'm not doing teaching currently, and partially because I have rediscovered that the Python ecosystem is flooded with "tools". Really, I would like a rewrite of Staffeli in a language that just does more out of the box instead of having to pile on this and that tool to get basic sanity. Golang is the obvious candidate. The language is simple, so it's hard to overnegineer your code, is statically typed, has a linter out of the box, and the library support for a Staffeli-sort-of-task is great.

That aside, the point of Cachable* was to designate objects that can be retained on disk to avoid extra requests to Canvas as these are sloooow on our Absalon system. The point was also to have expiration time stamps in there, but the design never really properly materialized. I still think this is a problem worth solving - response time on Absalon is still herendous, and I have run into synchronization issues due to stale data on my disk.

[sshine]

I like the folder structure, but I sense that there is a reference/naming ambiguity in the command-line tool when referring to e.g. "subs/3". Sometimes the '3' part is a glob-style pattern on the course or assignment name, and at other times that specifically chosen substring becomes the reference for the assignment. Sometimes it simply refers to the directory; e.g. the tools that split assignments into groups.

The Cachable stuff also confuses me. In particular, when extending the CLI, I didn't know when to explicitly cache stuff and when stuff was implicitly cached anyways. Maybe having a policy in a design document is the way to go. A policy could be that caching only happens at particular layers, so makers of high-level tools don't have to understand when caching happens. Another policy could be on how/when to pass parameters for enabling/disabling the default caching behavior.

There are probably some sane defaults, but I imagine they often depend on workflows. Maybe we should have a workshop where we start by discussing our preferred workflows and finish by writing the tools that enable them? In particular, I am not happy with Staffeli's way of handling resubmissions and its inability to give a course/assignment overview for who has passed what, which resubmissions have not been corrected, and which submissions are overdue.

[nqpz]

We also need to discuss how much functionality we want in the core Staffeli CLI tool, and how much should be done by using Staffeli as a library. This depends on how different the workflows are.

[sshine]

With a modular CLI tool, we can just write our own staffeli extensions, like I intended to do with your group splitting scripts. This is git-like I think. Focusing on what is "core Staffeli" is good, because the more we can narrow this down and get right, the more consistent other tools will be.

[athas]

I would prefer a single Staffeli CLI tool that can do everything. It makes it easier to ensure consistent quality and eases documentation. There are not that many different ways to manage a course, so there is no need for a plugin mechanism, I think.

[sshine]

@Athas: The point here is prioritizing "everything". I just meant that I would like some of the CLI tool sub-commands to be handled in Python sub-modules.

[oleks]

@Athas the down-side of a single tool that does everything is that you create a great barrier of entry for new users. New users seem to appretiate small tools they can understand rather then big tools that can do everything. Also, I find Python APIs a great help for scripting various workflows.

[oleks]

So when is this happening?

[athas]

I don't think new users appreciate small tools. In practice, the most popular tools seem to generally be uber-tools that do everything. We don't even have to look at consumer software for examples. Consider grep-alikes like ack and ag (the Silver Surver). Or, for that matter, the replacement of sed/awk/cut by Perl.

-- \ Troels /\ Henriksen