spreadubuntu team mailing list archive

[Neal Bussett <neal@xxxxxxxxxxx>]

For the DIY section of the website (diy.spreadubuntu.com), we've planned 
on having all the content accessible (and originally hosted) on bzr. 
The website will need to interface with bzr, and they'll need to stay in 
sync.  Below is my proposal for how to structure the data in bzr and 
interface with the website in a simple and effective manner.
This proposal is submitted for discussion to this list, in hopes that we 
can discuss and resolve any shortcomings; I have listed a few problems 
with this particular implementation at the end of this email--when we 
implement this for real, those won't exist.


For each item in the database include a description file that contains
all the proper meta-information.  This would contain all the "about"
info--creator, version, description, etc--as well as point to all of the
data for the item itself.  This allows us to have multiple files per
entry, and also gives us a way to support translations.  Each 
translation would simply be a separate entry in that file, as well as 
including places for the language specific about information.  The 
metafile also will allow us to link the various source files for each 
entry as well.

The directory structure of the repository could have a number of
successful layouts, all of which will be independent of the
classification for the site itself (ultimate classification data is
included in the metafile), the directory structure only aids in
organization for people who wish to commit/checkout/browse bzr itself.
The root of the repository would contain a number of directories for all
the main categories (posters, images, stickers, whatever--we can decide
on these whenever), and then inside each is the projects itself.  If we
want, we can further subdivide these directories into subcategories.
Each item gets its own directory (mainly to get rid of filename
collisions) which consists of the above mentioned metafile, and all
related files.

How this interfaces with the website is that at each commit (or at a
given time frame) the website diffs the bzr repo between the current
version and the last version it saw, and then uses that data to update
the database held locally (on the diy.spreadubuntu site).  It updates
its description fields (from the metafile) and then copies over any
changes/additions in the files itself.  If we need to (bandwidth becomes
a problem), we can do some more work on the diff analyzer and have it
only update the files/fields that were modified, but at this point in
time, I don't really feel its prudent (a lot of work on the parser, for
marginal bandwidth decrease).

The metafile would look something like this (whether we want plain text,
or XML is yet to be determined), this is just a rough depiction, but it
provides an example:

Author: Joe Smith
Name: Installfest Poster
Time: 2008-06-27[time time time]
Version: 0.1.0
Category: Poster
[en]
Data: installfest-en.pdf
Source: installfest-en.svg
Description: This is a poster for an installfest, blah blah blah.
[de]
Data: installfest-de.pdf
Source: installfest-de.svg
Description: Dies ist ein Poster fur ein Installfest, bla bla bla.

This sort of structure maps to a database rather well, your primary key
for any particular entry is a UID plus the language code.  I imagine 
we'll have one table for the locale independent info, another for the 
localized information, and then one more with the data itself.  Plus one 
more that is simply the UID plus any supported country codes, so we can 
get that information.

The above example (and database structure) may have problems if there
are multiple files per item (multiple data files or multiple source
files).  There are a number of ways we could expand upon this, but I'll
leave those for a follow up email.  This should also probably be
expanded to include multiple sizes for things (pictures or logos or
whatnot), which is something else we'll have to look into.


I look forward to comments and discussion from everyone,  Be sure to ask 
for clarification if anything is unclear.  I'll try and put together 
some better visual aids within the next few days.

Neal Bussett