Apixel COMET - Learning Record Store



When using Comet there are a number of items of which you should be aware. Please take to time to read and understand them as they could impact on your usage of Comet.


Normally an LRS is a "closed" system in that lessons, once uploaded, are not directly accessible ie, that lessons cannot readily, if at all, be changed. On the other hand, Comet allows direct access to the every folder/file within it. This means that you can easily replace an existing lesson.

While this can be a good thing you need to be very careful about the differences between lessons beause Comet may have already recorded information about the previous lesson which is no longer valid in the replacement lesson. So you must not simply replace lessons in Comet's 'lessons' folder with new lessons without being fully aware of the possible negative repercussions.

If you are unsure about what effects the replacement lesson may have it would be better to upload the lesson as a new lesson and add it to an existing course while first removing the "old" lesson from the course.


If Comet has been setup to use an MS Access database then:

  1. You should take steps to make sure your database is secure. That is, a user must not be able to enter a URL for the database into their browser to then download the database.
  2. You also need to be aware that MS Access has some limitations they may be relevant when used in an LRS. Specifically, MS Access can support up to 255 concurrent connections (as opposed to users) but it is better to have fewer than 10 concurrent connections. While it's unlikely that 100 users accessing the database concurrently will actually exceed the concurrent connections limitation (connections in Comet are only kept open for as long as actually needed), it is possible. For more information see: Access 2010 Specifications.

It is required that users' and trainers' usernames are an email address. Generally an email address is unique and Comet may use it (if properly configured) to send emails.

A trainer's username must not also be used by a user because the trainer's use of it takes preference. That is, the person will not be able to sign in as a user, only as a trainer.


Comet is not 100% SCORM compliant. While Comet is capable of accepting SCORM 1.2 and 2004 compliant lessons it does not support all the data models of SCORM. The main models that it does not support are the interaction (question) based ones. That is, while completion, scoring and success in a lesson is tracked the granular requirements to track interactions are not.


Names/titles for lessons, users, courses, trainers, groups... may not contain the percentage symbol (%).

Usernames and passwords may not contain these:

  • percentage (%)
  • astericks (*)
  • forward slash (/)
  • left square bracket ([)
  • right square bracket (])
  • semi colon (;)

Also, in usernames and passwords any occurances of multiple contiguous minus signs eg. -- are reduced to single minus signs.


There is a "simple" check made of email addresses entered for trainers and users
The email address is to:

  • start with at least one character (alphanumeric including the dot)
  • then the at (@) symbol
  • at least one character (alphanumeric)
  • a dot (fullstop)
  • and finally at least one character (alphanumeric).

This means that otherwise "valid" email addresses that may contain apostrophes or other punctuation cannot be accepted.


Internet Explorer 8 or 9 (may) throws errors with your Tin Can content.

The Tin Can specification describes the "IE mode request" ("HTTP emulation") ie the way Internet Explorer may send data to the server using cross resource requests (CORS). Internet Explorer 8 and 9 have two problems related to CORS:

  • They won't do PUT/DELETE requests cross resource,
  • They won't do any requests over a character limit of 2048 characters

For these reasons when either IE8 or 9's is detected and the LRS is seen to be cross resource or any IE version with the overall request exceeding 2048 characters then the IE mode request starts and the request is switched from a normal request to one where the HTTP method is emulated via a "method" query string parameter.

The fault is not with Comet. If you do experience errors then the developer of the Tin Can content should be contacted for them to see if there's a newer version of the TinCanJS, from Tin Can API, that resolves the current error(s).


Deleting users, courses, groups...

When, say, a user or a course... was deleted from version 1 of Comet the data was not actually deleted - the data was marked as archived so (theoretically) the data could be retrieved if necessary. This is no longer the case with version 2.

Deletions in version 2 result in any and all the associated data within the database to be completely removed. Removed data cannot be retrieved.

You should consider making a backup of the database at regular intervals.



© Copyright 2016 Apixel Pty Ltd, All rights reserved