Step 44 – Basic Structure of the Caching RTE

Time to sketch out the structure of my caching RTE code. Just to recap, here’s the current version of the VSSCORM RTE which has no caching mechanism – all transactions are immediately reflected in the persistent storage (LMS database).


In the new version, I’m going to create a set of JavaScript variables to act as a cache for local responses to LMSSetValue() and LMSGetValue() calls.


The server-side setValue.php and getValue.php functions will no longer be needed – all LMSSetValue() and LMSGetValue() API calls will interact with the cache on the client side (the browser) – but I will need to create a new commit.php function to handle the LMSCommit() API call.

Finally, I need somewhere to locate this cache and, rather than create another document/file/frame, I’m going to locate it in the header of the ‘api.php’ file. This makes sense because it’s also where the LMSSetValue and LMSGetValue functions are implemented.

Next time – create the cache code in api.php.

This entry was posted in Run Time Environment. Bookmark the permalink.

1 Response to Step 44 – Basic Structure of the Caching RTE

  1. Vedat says:

    libcanberra can do that for you just fine, just set the CA_PROP_MEDIA_FILENAME property when cniallg ca_context_play().ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME, path, NULL);If you need this from a shell use canberra-gtk-play which basically does this but a lot fancier.Note that while just passing the one filename is sufficient we encourage you to pass more properties, to easy a11y, yadda yadda.

Leave a Reply

Your email address will not be published. Required fields are marked *