Free Games Media Repository
===========================

Storage:
========

The storage used for the repository should full fill the following
goals:

 * it should not limit the game data files to be stored in any way
   (3d, 2d, texts, etc), but it might provide special features for
   some types of data (automatic thumbnailing and such)
 
 * it should allow to store meta information such as author, license,
   date of creation

 * it should allow to group or link multiple works together

 * it should be 'human readable' thus must not require any special
   tools to be manipulatable or viewable

 * it should be robust against hostile users, changes to it,
   especially the metadata, need to be undoable with little effort.

 * it should be conflict-free and permanent for the game data itself,
   no added game data should be able to overwrite an already existing
   work

 * it should not allow duplicates of the same artwork 

 * it should be lock-free

 * it should be self-validating, corruption of data should be easily
   detectable and correctable, if damage happens it should be limited
   to small portions of the data

 * it should allow easy merging and splitting repositories of the same
   type, thus for example allowing to store the repository on two
   different servers or to add content to an 'offline' repository that
   is than merged into the online one

 * storage and frontend for browsing the content should be seperatable

The following following simple design should accomplish these goals,
this design is only meant to address the storage issue for the
content, a frontend that provides browsability can be developed
seperatly:

 * each file of gamedata is stored in a directory named by its md5sum,
   thus it is save against naming conflicts with other datafiles and
   is also self validating, changes to the data can be detected by
   checking it against its directory name

 * gamedata itself is stored in the md5-directory as a file named
   '=data'

 * additional metadata is stored in that md5-directory, naming is
   '=<VALUE>', where <VALUE> can be author, license, filename or
   similar things

 * related work could be handled via a '=related' file which contains
   whitespace seperated entries of md5sums (needs a lock) or by a
   related/ directory which contains files with md5sums (lock free)

 * changes to metadata can be recorded in an append-only textfile of
   the form 'PROPERTY OLDDATA NEWDATA'

   "author" "Joe User <joy@user.org>" "Joey User <joey@user.com>"

   and thus be relativly easy undone.

 * zip or directories full of gamedata could be unpacked by placing
   each file in an own gamedata-md5sum directory and by providing
   additional gamedata-md5sum directories with a '=type' of
   'directory' where the '=data' field points to the content of the
   directory

 * usefull manipulation of the repository will already be possible
   with simple shell scripts, since everything is stored in plain
   files

 * comments to gamedata can be stored as gamedata itself, they just need
   a special '=type'

 * different 'domains' of gamedata (aka directories with md5sum dirs)
   could be added to seperate gamedata from automatically generated
   thumbnails or comments

Example:
========

If a user adds a blender file called foobar.blend to the repository it
will create the following directory entry:

82ff672b6d85258d91fc42171a43f97b/
 '=filename'  => 'foobar.blend'
 '=keywords'  => 3d
 '=type'      => application/x-blender
 '=ctime'     => 1095125348
 '=data'      => The file itself, running 'md5sum =data' gives '82ff672b6d85258d91fc42171a43f97b'
 '=author'    => Joe User <joe@user.org> 

The metadata fields are either filled with meaningfull defaults or let
empty so that the user can add metadata where necesarry.

Frontend:
=========
[to be written]

# EOF #