Table of Contents
Scorm Player Support
Requirement
- The content player should be able to play scorm content.
- The system should be able to import any SCORM package (2004 latest edition).
- The scorm player would preview the content and allow to make progress.
- The player should be able to play content available on cloud (like Amazon S3 ..).
Details about SCORM
- runtime API reference - http://scorm.com/scorm-explained/technical-scorm/run-time/
Implementation
A prototype is built based on the initial understanding of scorm specification which covers the following.
Unpacking the Scorm PIF
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
To be done
- Unpacking the content stored on cloud(like Amazon S3..).
- Modifications required to scorm gem code.
- The gem has support for SCORM 2004 3rd edition and SCORM 1.2 versions of manifest. Minor code change would make it to look “only” for SCORM 2004 4th edition.
- should be able to read <metadata> inside the <organization> and <item> tags of manifest file.(Only manifests with multiple <organization> s would require this metadata.)
- should be able to parse sequencing related tags in the manifest.
Previewing the content
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.
To be done
- Decide how to show the content(One SCO/activity per screen or entire course). Based on this the implemetation and db design should be tweaked to have optimized handling.
- Playing content on the cloud (like Amazon server ..)
- Handle rest of the runtime elements, objectives and sequencing.
- Implement better error handling and logging for runtime API methods as required.
- Save and track more data if required(like total time, num of attempts etc.)
Table design
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.)
Prototype scorm implementation
