Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

See also:

Table of Contents
outlinetrue

...

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.

  • 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.

...

Related documentation

Diagram source

DSL for https://www.websequencediagrams.com :

...