File Formats

Revision Control

Our undo, version control and merging behaviour will be provided internally by the use of the _mercurial: http://www.selenic.com/mercurial/wiki/ SCM. The mercurial system has a python API which fits in well with the choice of python as the implementation language for MysteryMachine.

Mercurial supports case sensitive and preserving repositories even on filesystems which do not have this properties.

It will do be possible to 'Save' a work point without creating a mercurial changeset (eg. doing a commit), this will be handled transparently by the system , except the fact the user will be prompted for a message when the 'save'.

Working format

The basic element of MysteryMachine is it

WARNING: `PluginArchitecture`:trac: is not a valid TracLink

which enables it to use many different file formats inside the revision control container.

However to start with I will only intend a single basic format options , although will try to ensure others such as XML can be added later.

To model the object nature of the database , the default store will use traditional filesystem abstractions which are support by most if not all modern operating systems, eg, file and directories. Not use of extended attributes or alternate data streams will be required.

Each attribute will live in it own file, the name of which reflects the attribute name (see NameSpace) however the use of the '.' as a seperator character will be used to indicate the internal handler for that attribute. It is possible though for an attribute to be composed of mutliple files, such as .patch.pre, .patch.post. These 'extensions' are known as 'meta-tags' inside MysteryMachine, and are read from left to right. Only the rightmost tag is handled by the core engine. Attributes from the same object are stored in a directory which is unique to that object, and similarly each object is a directory which is unique to it's category.

Finally files without any name are MysteryMachine metafiles and these files contain metadata about each object , category or the system itself. For instance the system is intended to support a '.parent' meta-attribute for objects indicating from which base object they might inherit attributes, similiarly the Templates are planned to by store in a '.templates' meta-category.

Save format

On disk, a complete game will be stored in a .MMPack file, this will be a the .hg/ directory and any other relevant mercurial control files stored in a standard PKzip container with the deflate option.

As noted above the working format can be quite wasteful of disk space although this is a abundant resource in most machines toady we use a zip file to allow many copy of the game in development , to be stored efficiently. Technically thought further saving may be possible be the use of the mercurial hard linking between repositories, - it is harder to manage and even harder for untrusted users to follow while shouldn't cause problems has the potential for violating the the principle of least surprise.