| Info |
|---|
See also: |
| Table of Contents | ||
|---|---|---|
|
...
XQueue has a separate user model that has no connection to edx-platform users. Service accounts must be created directly with XQueue, and clients must use basic (session) auth to communicate.
API Endpoints
There are three groups of HTTP web APIs exposed by XQueue, all of which communicate using JSON.
...
Stop generating PDF certificates in favor of Web certificates. Easier said than done but this is absolutely the direction we need to go.
Decrease coupling: pull the LMS XQueue interface out of CAPA, or at least remove the code dependency between Certificates and CAPA.
Convert all hard-coded queue names in edx-platform to be configurable. You never know when this could become useful...
XQueue Core
Move away from the push grader model. XQueue should really only exist to handle asynchronous communication with pull graders. For push graders, synchronous communication makes more sense and could be done using a separate XBlock or an LTI tool. (This includes the MatlabInput use case as well, as that's effectively a push grader.)
UPDATE: Push grading has been deprecated. 🎉
Remove get_queuelen. I know it's nice to have a "peek" operation but it's not really that interesting. Even XQWatcher doesn't bother with it and instead just tries repeatedly to get_submission until successful.
NOTE: This solution is better than the one proposed here (in response to a security issue): /wiki/spaces/PLAT/pages/49873364
Bulk get submissions for parallel grading (and bulk push back in). Jobs typically come in waves.
Switch from using a separate user store and session auth, to using the edx-platform authentication backend and signed JSON Web Tokens for authorization.
This would require that each queue is mapped to a whitelist of allowed producers and consumers (user authorization), and those clients would need to be appropriately scoped (app authorization).
Possible scopes (just brainstorming): "xqueue:submit" (basically just the LMS), "xqueue:score" (all grader clients). "read/write" and "pull/push" don't really make sense as all XQueue clients need to both add and remove from queues. If we want to keep it simple, we could just have an "xqueue" scope.
...
XQueue: https://github.com/edx/xqueue
Contains the Python code for the Django-based IDA.
Pull grader client: https://github.com/edx/xqueue-watcher
Contains the base Python code for Flask-based XQueue watchers.
The actual graders used on edx.org are maintained by the course authors in separate Github repos.
One example of a (private) Github repo where MIT graders are kept for one course: https://github.com/mitodl/graders-mit-600x
Push grader client: https://github.com/edx/xserver
This repo is now archived and is read-only. Push graders are now deprecated and removed.
Related documentation
Diagram source
DSL for https://www.websequencediagrams.com :
...