Update: The Output of Project Tin Can is Experience API.

next generation scorm evolution project tin can
 

Ready to really dive in?
View the full
Tin Can API spec.

View the Tin Can API
“quick start” guide.


LRSs Will Have To Store and Manage More Data

LRSs will have to store more data and query a lot more than traditional LMSs.

As of now, data stored using the Tin Can API isn’t as structured as LMSs are used to. There will most likely need to be new methods of storing and querying data more efficiently. Luckily, storage is cheap.

We’re going to be prototyping around these ideas, and we’ll be able to provide some answers and suggestions as we go.

In the meantime, what are your thoughts/suggestions for how this data is stored and queried? We really want to know what you think, so let us know in the comments section below.

SCORM 2.0 next generation project tin can

  • glenn

    I’m thinking it will need to be a document orientated database – maybe CouchDB (http://couchdb.apache.org/).

  • Anonymous

    We’re initially prototyping using mongo, which is similar (http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB).

    It’s certainly making the initial storage side easier, reporting may still be a little tricky.

    I’d like to have a SQL/RDBMS based prototype as well, as I expect there are plenty of potential adopters who will want to stick with their RDBMS, and not manage two DBs.

  • ingthing

    DynamoDB

  • marshall

    MySQL is very widely used. I’d like to see a solid data structure, with consistent properties/values before the tables are laid out. With such a moving target, with so many variables, any database would have to be renormalized as the API stabilizes.

  • So, I checked both Rustici’s and ADL’s githubs and i’ve prototypes utilizing both nodejs + mongo and python + mysql. Which one was the better fit?

  • bsc_scorm

    Either can work well. Particularly with the changes made in .95, the main database workload for Tin Can is:

    – Store many potentially large objects, retrievable by ID

    – Enable retrieval of statements by a variety of filters in addition to their ID (see query API)

    Either stack can handle that workload. nodejs and mongo have an extra advantage in their native handling of JSON. In either cases, some objects will be large enough to merit storage outside of a DB on a filesystem or other ‘large object store’.

  • Argent

    Any LRS on the market? It is a whole storage management system?

  • Brian Miller

    There are 2-3 that I’m aware of already. Our SCORM Engine product can be licensed to include an LRS and our SCORM Cloud hosted solution provides access to an LRS at all account levels (you can sign up for a free account).

    https://scorm.com/scorm-solved/scorm-cloud-features/tin-can-api-scorm-cloud/

    Sign up: https://cloud.scorm.com/sc/guest/SignUpForm

    You can also check out the Wax LRS by Saltbox and VTraining Tracker, there may be others as well.

    I’m not sure what you mean by “whole storage management system”, if you can clarify I can try to provide more details.

  • Paul Swennenhuis

    I’d like to suggest BaseX.
    http://basex.org/
    It’s a very fast and powerful XML database, and allows for mixed content. And mixed content (shorter or more elaborate statements) seems to be typical for an LRS.

Click to Hide Advanced Floating Content

Coming soon!

SCORM.com's same great content is getting a brand new look.

Subscribe to be the first to hear of the relaunch.