Javascript SCORM API commit - async or sync?

Question

We are currently facing a design problem implementing a SCORM LMS System. For example, the API defined a function LMSCommit which must return either 'true' or 'false'. Within that method, our LMS has to make an asynchronous call to a server side service, using a callback function containing the success or failure message in its argument. We claim, that this is simply not possible! Yet we think its worthwhile to ask some pros whether there is something we are missing here.

The SCO (no influence on our part) calls the method like this:

var result = LMSCommit('');

Our LMS (influence on our part) we implement something like this:

function LMSCommit(useless) {
  callOurServiceFunction(function(Status) {
    // what am I supposed to do here in order to put status into
    // the return value of the outer function???
  }

  // fake true as the callourServiceFunction returned immediatly,
  // no idea how I can use Status to create a return value
  return 'true';
}

Are we missing some fancy trick here or is the SCORM Standard simply "disputable"?

Scion

Looks like the "SCO" assumes your function is synchronous, although it isn't. Any chance you could change that code? – Superstructure

Why do you have to make an asynchronous call? – Arrival

Because the API for commincating with the backend server only supports asynchronous calls... – Scion

Answer 1

It's normally implemented using asynchronous code with a fairly worthless "true" value returned. This is well-known by SCORM course developers, who have learned not to rely on the Commit return value for anything important. In this case, all the return value means is that an ajax request was fired.

If you implement Commit using the synchronous approach, the course will appear to lag and stall while waiting for the return value, which will guarantee a ton of complaints and claims that your SCORM engine is broken.

Very frustrating for people in your shoes, but unfortunately, there's nothing you can really do about it.

A little background for those less familiar with SCORM:

SCORM, which is a compilation of specs, not a true standard, received its last major update in 2004. (The updates since then have been minor, no major architectural changes.) This means it's ten years old. SCORM 1.2 is even older. The ADL has announced they are not going to be updating SCORM anymore -- the lid is closed, as they say.

To put things in perspective, the last major SCORM update was released when IE6 was the dominant browser, Google Chrome and the iPhone didn't exist, Yahoo and RealPlayer were relevant, Facebook was a dorm room project, and everyone thought Adobe Flex and RIAs were the way of the future. It's a different world now... if they were to start over, I'm sure they would have gone a different route. This is where xAPI (aka Tin Can) picks up; it uses a different communication model (RESTful API), and can be used to replace SCORM in LMSs that support xAPI. (Note xAPI is still not widely supported yet.)

xAPI links if anyone reading this is interested:

• http://www.adlnet.gov/tla/experience-api/
• http://tincanapi.com/
• http://en.wikipedia.org/wiki/Tin_Can_API

Angstrom

If you ever have a SCORM question, and you get an answer from @pipwerks, use it. He's the JS SCORM man! – Muddleheaded

Answer 2

I had to write out a AJAX queue system as I tried to keep async calls until the browser exits and switch to sync.

But you have several scenarios to check -

1. Is the session initialized
2. Is the session terminated
3. And the "No Argument was expected" aka your 'useless' remark haha.
4. Now you can tally up total time, and manage anything else that may need to be by the LMS (progress) etc ... LMSCommit sounds like SCORM 1.2 though so from memory you may not have to do that.
5. Send your student attempt to the sever

Now keep in mind HTTP requests get tricky. Past Commit calls can arrive later than a current submission. I time stamp mine so I don't end up with a collision. Also this queue allows me to submit in order as you don't want prior Commit spam to arrive after the exit thus overwriting cmi.exit and anything see that happened in those milliseconds/seconds.

There are LMS's out there that behave in a non-cached way. Ever get/set is a round trip to the server. Hence, you see a 50-400ms lag per request which equates to 3-6 seconds of a stuck user experience for the student.

If you've cached the student attempt and are just committing it, then your sending say 5-12KB of data over to the server. And if you've taken a cached-hybrid approach your only sending whats changed.

This all falls in line with the power going out, internet connection loss and in general how you want your Runtime to behave.

So per the above 'list' if I'm able to add it to the queue I respond 'true' and if it meets any of the other criteria 'false'.

GL, Mark

Lydialydian