Runtime API and Data model

The details of the runtime API and data model implementation and current status of them can be found below.

Good references -

http://scorm.com/scorm-explained/technical-scorm/run-time/run-time-reference/

http://scorm.com/scorm-explained/technical-scorm/run-time/

The runtime API is a javascript API which exposes an instance of it as a variable “API_1484_11”. The sco interacts with it by calling the methods. The implementation of if is found in the source code under /public/javascripts/runtime.js.

A new instance of API can be created as below

var API_1484_11 = new RunTimeApi();

As per scorm 2004 specification, the runtime needs to expose the following methods to an SCO.

Initialize()
Terminate()
GetValue()
SetValue()
Commit()
GetLastError()
GetErrorString()
GetDiagnostic()

We expose all of the above methods and also some more methods for error handling which might not be used by many SCOs.

The current status of the runtime -

• The implementation of all the above mentioned methods is complete.
• We send a request to server with runtime data when ever a call to “Terminate” or “Commit” happens. The runtime data is stored in an instance variable 'RTStore' and also copied to _RunTimeDataStore. We use '_RunTimeDataStore' to send it to server and access out side API. This data can be read/written by SCO through API object. We also maintain another variable '_RunTimeSessionStore' which holds information of current scrom session id, preview or not, fullscreen mode or normal and current activity. This is set by server on launch.
• We also have a basic prototype of error handling for getValue and setValue methods.

Improvements Needed -

• The runtime should be able to handle sequencing.
• The exception handling and logging can be improved as needed.

The Scorm 2004 data model is the list of the attributes an SCO can either set or get or boht set and get through the API.

We support the following attributes which are minimum as per Scorm 2004 suggestions.

Note - (RO - read only, WO - write only).

Also, we have the following limitations on scorm gem that parses the manifest file. We need to patch it to support these.

Limitations in manifest parsing -

• Support multiple ornanizations - We can't support multiple organizations at this moment which is a rare choice by scorm content. Cannot read <metadata> inside the <organization> and <item> tags of manifest file.(Only manifests with multiple <organization> s would require this metadata.) It is a regular practice that a scorm content always has one <organization>. So, support for this is not required immediately. But this can be added some time in future.

• Sequencing and Objectives - Cannot parse sequencing related tags and objectives in the manifest.

The runtime API is a javascript API which exposes an instance of it as a variable “API”. The sco interacts with it by calling the methods. The implementation of if is found in the source code under /public/javascripts/scorm/scorm_12.js.

A new instance of API can be created as below

var API = new RunTimeApi12();

As per scorm 1.2 specification, the runtime needs to expose the following methods to an SCO.

LMSInitialize()
LMSFinish()
LMSGetValue()
LMSSetValue()
LMSCommit()
LMSGetLastError()
LMSGetErrorString()
LMSGetDiagnostic()

We expose all of the above methods and also some more methods for error handling which might not be used by many SCOs.

The current status of the runtime -

• The implementation of all the above mentioned methods is complete.
• We send a request to server with runtime data when ever a call to “Terminate” or “Commit” happens. The runtime data is stored in an instance variable 'RTStore' and also copied to _RunTimeDataStore. We use '_RunTimeDataStore' to send it to server and access out side API. This data can be read/written by SCO through API object. We also maintain another variable '_RunTimeSessionStore' which holds information of current scrom session id, preview or not, fullscreen mode or normal and current activity. This is set by server on launch.
• We also have a basic prototype of error handling for getValue and setValue methods.

Improvements Needed -

• Same as scorm 2004.

The Scorm 1.2 data model is the list of the attributes an SCO can set and get through the API.

We support the following attributes which are minimum as per Scorm 1.2 suggestions.

Note - (RO - read only, WO - write only).

Limitations in manifest parsing -

Same as scorm 2004.