Now, it’s time to start up again and tackle a couple of issues that I’ve been wanting to deal with:

• error codes and error messages;
• a logging capability to help diagnose SCO to LMS communication problems.

So, with that in mind, in my next post I’m going to start attacking the error codes and messages.

This will – inevitably – involve quite a few changes and, during that time, things may well break. So please bear with me while I make the transition.

There are basically 2 areas that I believe need to be addressed to make the VSSCORM 1.2 RTE code more robust and reliable.

1. Error Handling
   I thought, at first, that well-behaved SCOs wouldn’t trigger any error codes so I haven’t spent much time on this aspect of the code. But that’s not always true – I’ll talk about an example in an upcoming post where a SCO uses the error code to see if an optional data element has been implemented or not before trying to write to it. So I think I need to take some time to implement error handling as specified by the SCORM 1.2 RTE specification.
    
2. Optional Data Elements
   The first version of the RTE implemented only the mandatory data elements, and this seems to be good enough for many (most?) SCOs. But I’ve been coming across some SCOs that require the use of optional elements. So I think I should implement them when I can.
    

Then there’s the VSSCORM Manifest File Reader. It seems to be working pretty well, but I think the best way to make sure would be to build it into a “mini-LMS” which would allow a user to:

• Upload a SCORM content package (including multiple-SCO packages)
• Choose and run a SCO using the VSSCORM RTE

I could also use this as a test harness by implementing some simple tools to look at the state of the database and the API cache as well as monitoring/logging the API calls for debugging purposes.

So that’s what I’m thinking. However, if you have any personal opinions on where I should be taking the project, please let me know!

Next time – some interesting problems raised by a reader’s SCO.

1. I’m going to limit the investigation to SCORM 1.2. There’s not many people using versions of SCORM earlier than 1.2, and SCORM 2004 is a lot more complicated. But, if I can figure out SCORM 1.2, that should be a good stepping stone if I choose to go further.
2. I’m going to look for a solution that requires only JavaScript on the client side i.e. no Java. A lot of businesses have trouble allowing Java through their firewalls, so a solution that avoids it from the outset would seem to make most sense.
3. Rather than build it into a real LMS, I’m going to mimic the LMS side of things with some simple PHP coding, and use a MySQL database to store the data.

That’s it. I’ll let you know if I can think of any more.