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'); ...
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.