A prototype is built based on the initial understanding of scorm specification which covers the following.
We use scorm gem to unpack the scorm package file and create a course structure.
Scorm Gem (more info - https://github.com/mindset/scorm)
Installation -
gem install scorm
The content is played from the unpacked scorm PIF. We have the sample runtime API that implements all the methods required for the SCOs to establish connection and exchange data with server. We handle a few runtime elements. The elements values are updated in the db on either commit and terminate actions.
Table name - scorm_packages
| Column_name | type | Description |
|---|---|---|
| id | integer | primary key |
| name | varchar | Name of the scorm package |
| location | varchar | The path where the package is stored |
| manifest | longtext | The parsed manifest object which is used as the course structure |
| created_by_id | integer | foreign key to the users table. User who has uploaded the package. |
| updated_by_id | integer | foreign key to the users table. User who has last updated the package. |
| created_at | date_time | created date |
| updated_at | date_time | updated date |
* Note - The manifest column contains the ScormPackage::Manifest object which is generated after parsing the PIF.
Table name - scorm_sessions
| Column_name | type | Description |
|---|---|---|
| id | integer | primary key |
| scorm_package_id | integer | foreign key to scorm packages table. The scorm package id corresponding to which this session is created |
| user_id | integer | foreign key to the users table. User who has launched this package. |
| runtime_data | integer | This is a serialized hash containing all the runtime data of all activities. |
| created_at | date_time | created date |
| updated_at | date_time | updated date |
* Note - The table scorm_sessions is designed assuming that all the activities of the course are shown at the same time on the screen. So, the runtime_data contains the information of all the activities . If we decide to show one activity at a time , we can save each activity's data in a row. So, the runtime_data would just contain information of one activity. Also, depending on the amount and kind of information we want to show we would modify this table(like number of attempts, total_time etc.)