Media Package Format White Paper

This was taken from zzorn's recent post (Subject: [WF-Client] Media Package Format and Client Side Media Library Date: 04 Feb 2002 20:45:08 +0200) to the WF-Client mailing list.


We will need some common format for media packages, and conventions of how they are handled. I don't know if this has been discussed already in connection with the media repository, but my impression is that there is no common agreed upon media package format.

The idea presented below specifies a media package format that describes the package and links to contained media files of different types, and a client side media library that implements media downloading, caching, handling / decoding, and gives clients freedom in the way they treat media by allows them to register custom handlers for different media types.

If the general concept is accepted after review, the next step would be to specify the package format and start the design of the client side media library.

Please comment, and suggest improvements or possible alternative solutions.


Media Type Examples

Some examples of possible media types:

And so on.

Not all clients need to support all different media types, and not all different media types are present in each media package.

Media Package

A media package could be a lightweight structured document (for example xml or atlas based). It has a name (unique?), id? (unique), description, license, version number, and version history. The version history contains entries with version number, date, author doing a change, and a comment about what was changed.

It could also have a list of required, optional, and recomended other packages (research into exsiting package system such as debian and rpm3(?) could be done to get additional ideas of what kind of package management and version dependency we are likely to need).

This way we could also have 'virtual packages', that is, packages that list some other packages as required, but don't themselves have any associated media files.

Each media package would also have a list of the media files it contains. This list would contain the media file type, an exact filename or id, the current revision number of it, and a version history for it. The version history contains entries with revision number, date, author doing a change, and a comment about what was changed.

So the media package file in itself doesn't contain all the media data.


The media repository would contain the media package files, as well as the media files themselves.

Clients would use the media library to download the media packages (not the actual media files yet), and then when some media is needed from some package, one format is selected based on which ones are available in that package, what media formats the different media handlers in the media library support, what types of media the client supports, and what preferences the user has specified.

The media files, and intermediate output data for the client generated by the media type handlers, are cached on the client. Least used / most un-recently used data is cleared from the client side cache (generated data first, because it can be re-generated without downloading) when it starts to grow full.

Media authors can use various tools to update media packages. When some file in a media package is updated, an event is added both to the version history of that file in the package, and to the version history of the package itself.

A media file could perhaps be shared between multiple packages too.

A central repository is probably used for uploading, and is mirrored by media servers that clients use.