Librarian and the Library

Posted on December 7, 2014 by Alex Sassmannshausen

So far disciplines have been simple, single file Guile modules stuck in the (glean store) namespace. The simplicity of this approach is its main attraction: creating a new discipline involved merely adding it to that directory or copying the discipline file into the user's discipline directory at ~/.glean/library/store/.

But there are downsides to this approach too:

In particular, I'm working on a schema by which metadata which can be used for fine-grained module versioning, and for maintaining synchornicity between the disciplines kept in the library and the abstract representation of those kept in the lounge. This schema would involve the automatic generation of a metadata file as part of a discipline, prior to the discipline's distribution. The metadata file is then used to allow this new discipline (or the new version of an existing discipline) to co-exist with older versions, and to tell the lounge how to transition from its current abstract representation to an up-to-date one.

To this end: enter the guix-y abstraction of store -> catalogues -> current-catalogue!

The Store

The original library store still exists, but it is no longer used to load files directly into the library.

We're also no longer using a ‘core‘ and a ‘user‘ discipline store — all disciplines are installed directly into the store directory, which is then used as the basis for…

The Catalogue Store

The catalogue store is new: it is a directory containing folders, each of which represent one catalogue — a snapshot of the currently active disciplines.

Each of these catalogues contain folders to create the (glean store) namespace, and then a collection of symlinks to actual disciplines in The Store.

This approach will allow us, in the future, to have different versions of the same discipline installed, and to then select which of those version is active at any given time by switching between catalogues.

In this model, installing a new discipline involves installing it in the store, and then creating a new catalogue which supersedes the current catalogue which now also links to the newly installed discipline.

Removing a discipline on the other hand simply involves creating a new catalogue superseding the current catalogue which omits the ‘removed‘ discipline.

As you might surmise: no data is deleted, so we should always be able to roll-back or retrieve data from previous disciplines.

The final piece in this puzzle is

The Current Catalogue

The current catalogue is simply a link pointing to the most recently installed catalogue in the catalogue store. When the library loads disciplines into memory it simply loads all disciplines encountered in the catalogue linked to by the current catalogue symlink.

At a later date we will no doubt implement selection of arbitrary historic catalogues for activation as a low-hanging fruit.

Conclusion

The mechanisms described above will serve literally as a foundation for a reliable synchronization mechanism between the library and the lounge. The aim here is a mechanism which enables content creators to ’tweak and forget‘, and enables users to keep their lounge data up-to-date transparently — that is, they should not even need to be aware that the abstract representations used for challenge selection in their lounge have bee updated.

For now, the next step is probably a license change from GPL 3 to AGPL 3.

Creative Commons Licence
This work by Alex Sassmannshausen is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License .