Sirikata URIs

Sirikata has a small helper application, slauncher, which launches sirikata: URIs from a browser. To make use of it, a user should run slauncher (or slauncher.exe) to register the URI handler. On some platforms, e.g. Windows, this requires administrator permissions. You can also explicitly request registration

  slauncher --register=true

Once registered (and possibly restarting your browser), you should be able to click on sirikata: URIs and you should be asked if you want to launch the application. Again, you can use slauncher yourself (e.g. from a script), explicitly specifying the URI:

  slauncher --uri=some_sirikata_uri

Except on Mac, you can unregister the handler too:

  slauncher --unregister=true

Sirikata URIs

Currently the URI format is very simple:

  sirikata:config_uri

where config_uri is a URI for a JSON configuration file using a scheme supported by Sirikata (e.g. http, file, or data). For example

  sirikata:http://pastebin.com/raw.php?i=MwZi4T0t

would run slauncher, telling it to load the configuration at the specified pastebin URL.

Why another application?

There are two reasons for slauncher. First, it lets us support launching different applications, and even launching multiple applications, in response to a URI click. It acts as a bootstrapper, loading a configuration file and executing the requested commands. This is useful, for example, to package a standalone application where the user runs both the space and the client. Second, slauncher can do some additional setup of the environment, e.g. syncing additional data before running the application, changing to the correct directory, etc.

Configuration

The structure of the configuration file is currently very limited. Here's a minimal example:

   {
       "app" : {
           "name" : "demo",
           "directory" : "demo"
       },
       "binary" : {
           "name" : "cppoh",
           "args" : {
               "object-factory-opts" : "--db=avatar.db"
           }
       }
   }

The fields currently recognized are:

• app.name - user-friendly name for the app
• app.directory - similar to app.name, but used for creating a private storage space for the application in the filesystem
• binary.name - the name of the binary to run (cppoh, space, etc).
• binary.args - custom arguments to pass to the binary

Things which are currently missing but need to be added:

• some way to specify additional resources that should be downloaded/synced prior to running (e.g. avatar.db in the example)