Translation(s): none

(!) ?Discussion

This page describes a simple way to publish data files using DDE.

In short

  1. In your home on, prepare a .json, .yaml or .pickle file with the data to export
  2. Alternatively, you can prepare a directory tree which contains .json, .yaml or .pickle files
  3. Mail asking to symlink it into /srv/

  4. You should then see your data published under

You can put any file in YAML, JSON or pickle format, with extension .yaml, .json or .pickle accordingly.

You can also split big datasets in smaller parts and organise them in directories. For example, suppose you ask for ~user/dde to be symlinked as /srv/

Data file

Is published at



The content of the file can be any arbitrary combination of dictionaries, lists or scalars. Entries of a dictionary automatically create subnodes, allowing to access only parts of the dictionary.

Whenever you update a data file, dde should notice it and reload the new version.

Adding documentation

Note: this needs reimplementation, there is currently no way to provide documentation for static datasets. This documents the old way, I'm keeping it here as a reference for possible reimplementation ideas

DDE likes to describe the data that it contains, and you can help it.

To document the meaning of a directory, create a .doc file inside it containing normal UTF-8 text.

To document the contents of a data file, create another file with extension .doc.[FORMAT] next to your normal data file. The file should contain a data structure with the documentation of every node, for example:

cat > /srv/$USER.doc.yaml <<EOT
".": Information about $
 ".": Pages with build status of packages
 buildd: link to

  Co-maintainers are not listed
 igloo: link to igloo's buildd statistics
 svnbuildstat: link to svn build statistics
 ".": Quality Assurance pages
 lintian: Lintian reports
 lintianfull: Full Lintian reports, including "info"-level messages
 dehs: Debian External Health Status
 debtags: Debtags QA page
 db: user information
 alioth: alioth user page

There are two special node names:

There is only one convention for the contents of the documentation:

  1. One line with short description
  2. (one empty line)
  3. Long description as you please

Documentation is optional, but will greatly help people to understand the data that you are publishing.

Tips & tricks

Note: these are the tips&tricks for the old implementation; they do not make much sense anymore. They need rewriting once I finish reimplementing the static dataset documentation system

See also: