Over the last couple of weeks, I’ve had some very useful feedback and suggestions for the future direction of my project. And I’d like to thank everyone for the suggestions – I’m certainly going to try to address them going forwards.
However, there’s another problem that I need to address first. I’ve been using a system based on the VSSCORM RTE for some time, and it’s been working very well. But recently, I came across a SCORM 1.2 course (SCO) that caused the system to run really slowly. So I need to find out why.
Rev 1.0 of the VSSCORM RTE handles client-to-database transactions one-by-one. Every LMSSetValue() or LMSGetValue() call to the SCORM API results in an AJAX request being sent to the LMS server. This is a simple system to implement, and it’s also robust in the event that there’s a service interruption. But the course that was causing the problem was initiating 36 LMSSetValue() and LMSGetValue() calls before each and every page was displayed. And that slowed system response to a crawl. Here’s a (sanitized) example of what’s going on.
LMSGetValue('cmi.core.student_name');
LMSGetValue('cmi.core.student_id');
LMSSetValue('cmi.suspend_data','var1=1;');
LMSGetValue('cmi.suspend_data');
LMSSetValue('cmi.suspend_data','var1=1;var2=9;');
LMSGetValue('cmi.suspend_data');
LMSSetValue('cmi.suspend_data','var1=1;var2=9;var3=abc;');
LMSGetValue('cmi.suspend_data');
LMSSetValue('cmi.suspend_data','var1=1;var2=9;var3=abc;var4=185;');
LMSGetValue('cmi.suspend_data');
LMSSetValue('cmi.suspend_data','var1=1;var2=9;var3=abc;var4=185;var5=0;');
LMSGetValue('cmi.suspend_data');
...
The course is setting the cmi.suspend_data data element to represent the state of the course at any particular time. However, rather than do this in client-side JavaScript before initiating a single LMSSetValue() call, the developer has chosen to build it piece-by-piece in the database. So, rather than a pair of transactions (one LMSSetValue() to set the data element value, and one LMSGetValue() to check that the value has been recorded correctly) we have 18 pairs of transactions i.e. 36 AJAX requests in total. Whether this is a sensible approach or not (and I’m leaning towards ‘not’), it’s a valid approach under the SCORM standard and I have to grit my teeth and find a way to deal with it.
Let’s take another look at the SCORM 1.2 RTE specification. Nothing in the document says that data must be transferred immediately to persistent data storage and, in fact, the LMSCommit() call seems explicitly designed to support some kind of local (client-side) cache. In other words, changes to the data elements could happen on the client-side and not be reflected as changes to the persistent storage until the LMSCommit() function (or the LMSFinish() function which implies/requires LMSCommit()) is triggered.
So, for the next few steps in my meandering journey through SCORM, I’m going to work on creating a caching version of the RTE. I’m going to call it Rev 2.0 leaving me the room to extend the 1.0 series if necessary.
Next time – the basic structure of my caching RTE.