-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Look at whether suspend data can be made more efficient #1080
Comments
This commit adds a method `Numbas.storage.remove_default_keys`, which removes keys from suspend data objects when they have the default value. There's also some logic about not including list properties when the list is empty. I think this cuts the size of suspend data by about half. see #1080
I wrote some code to chuck out keys from suspend data objects when they have default values. That seems to have cut the size of the suspend data roughly in half, since most questions don't use most features. However, running the JSON through gzip and then base64-encoding it further cut down the data to between 10% and 20% of the original. This would save a lot of space, at the cost of not being able to read the suspend data directly. |
The problem is the |
Hi Christian. It was me that ran into this issue. I certainly don't have any big fixes, but I do have a number of small questions and/or thoughts that might help shrink the suspend data a meaningful amount, at least for the sorts of questions I code, and probably for others too:
|
|
Somebody encountered SCORM's limit of 64,000 characters on the suspend data. The LTI provider doesn't enforce this, but generic SCORM players do.
We should try to make the suspend data as small as possible, so that as many exams as possible will work. Obviously there has to be an upper limit on the size of an exam - an exam with 64,001 parts could never fit in 64,000 characters, as a simple upper bound.
At the moment, lots of values are included even if they have the default value. We could try only including keys if they have a non-default value.
Going even further, a lot of space is taken up by the names of object keys. If we use something other than JSON, then we could either assume we know the shape of the data and omit the keys entirely, or give a structure definition at the start.
The text was updated successfully, but these errors were encountered: