Hi Luke
Why not trust the LMS? Because most LMSs handle the SCORM data asynchronously.
When you first launch the course, the LMS gets the data from the database, then puts it into a JavaScript layer so SCORM can interact with it (the SCORM API). When you fetch data, you are typically fetching data that is in this JS layer, which was preloaded at the time the course was launched. Since it's JavaScript, it's loaded in the client.
Subsequent attempts to save data (commit) will first be stored in the JS layer on the client side, then pushed to the server via AJAX (xmlhttprequest) later. When you do a 'get' after a 'set', you are typically getting data from the JS layer -- the client side -- without the LMS actually checking the database to see if the data is there. This is what trips people up.
The LMS has no reason to re-fetch the saved data from the database, it assumes the data in the JS layer has been synchronized with the LMS database, so why bother making those extra trips to the DB? Just grab what's in the JS layer, handle everything on the client side.
The submission process (SetValue) is typically asynchronous. This means the LMS will often return a 'true' value indicating the SetValue call was successful, but in reality it's actually telling you the SetValue was successful in the JavaScript layer and not necessarily persisted to the DB. There is no guarantee the data was successfully persisted in the database, and no guarantee the connection to the LMS is still intact.
LMSs are kind of forced to handle it this way. xmlhttprequest has two modes: synchronous and asynchronous. Submitting data synchronously means all other JavaScript operations will halt until the result of the xmlhttprequest submission is received. This can take seconds (as opposed to milliseconds), which gives the impression that the course locked up and is broken, especially if the course makes multiple SetValue calls per page. LMS vendors want to avoid making the courses feel broken, so they use asynchronous submissions instead, which means they wind up faking the outcome of the submission -- they always say it was successful, and may return this 'success' value before the xmlhttprequest has even finished processing.
Getting back to your use case, if you're checking to see whether the connection is active, a simple GetValue will not be reliable, because the data is being returned by the JavaScript layer, which is already loaded in the client, and thus remains available even if the internet connection dies.
So to check if the internet connection is active, use methods outside the LMS (see links above for two approaches). There is no reliable way to check if the LMS is still available, except to try to load files stored on the LMS via xmlhttprequest, which is probably to slow and impractical.
Hope that helps
- philip