Thanks Dan and Matteo.
I fully agree with both of you on the SCORM module comments. Actually, the direction I've decided to take now is to implement a local plugin as a service. The new plugin will utilize the REST web service and provide a single endpoint for access. This seems to be the obvious solution since support for updates, database, events, etc. are all there.
I've already developed a modified version of SCORM for the main purpose of being able to store, manage, and deliver TIN CAN packages using those provided by Articulate for Storyline. Since Tin Can packages do not use the typical imsmanifest.xml but use a tincan.xml, I've had to address how the packages are identified, parsed, and handled much in the same way as traditional SCORMs. This allows use of all existing package management, delivery mechanisms, and tracking with minimal coding and no additional tables, reports, or gradebook handling. At present state, it is now able to handle the Storyline .zip packages as local uploads, downloads (local syncs), and external (using the URL of the tincan.xml file). In conjunction with the Tin Can plugin, the packages now launch with appropriate parameters providing all instructions needed (including an automatically generated token) for the Storyline packages to communicate with the Tin Can endpoint. This is necessary for tracking when using the Articulate Mobile Player.
The end result will be a fully functioning LRS that's independent from the SCORM module. However, logic will be provided to allow access to statements by Moodle modules. The plan is to provide some filtering of incoming statements/requests and detect if they are related to a Moodle module. If so, the module folder will be searched for a tcapilib.php file and associated helper functions. The module will have opportunity to intervene in LRS storage and response. In the case of SCORM, statements will be scanned for activity progress, completion and grade. Data will be mapped to SCORM cmi vars and stored as track information in the native SCORM tables giving access to all native SCORM reporting and tracking (somewhat the same as AICC). This opens the door for other modules to have equal access to the API.
LRS reporting is something we may not have a need for short term. So, there's opportunity for development of a plugin report. However, any reporting system given an access token would be able to pull and report on the LRS data. I plan to provide a couple of different permissions as part of the Tin Can plugin. Those can be expanded on as types of use expand.
For now, I'm working on the data table structure for the LRS. If anyone has any input as to how they see the data being stored in way that lends well to reporting, pass it on to me. I should be making additional progress sometime in the next couple of weeks.