Content types

Wed Jun 11 08:30:31 PDT 2008

Recently, GIO and nautilus have introduced the concept of content types,
which are similar to mimetypes and of the form x-content/foo. But
instead of individual files or bytestreams, content types apply to
volumes/directory hierarchies (mostly for use on removable media).
Typical examples are "Audio CD" or "Video DVD" or "Digital Photos". The
complete list of content types currently recognized by nautilus can be
found in /usr/share/mime/packages/nautilus.xml
( http://svn.gnome.org/viewvc/nautilus/trunk/data/nautilus.xml.in?view=markup )

It is useful to note that a tree/medium may match more than one
content type. This is perfectly fine; e.g. many phones acts as both
audio players, video players and digital cameras. 

Also, note that applications may need further information than just the
content type (e.g. x-content/audio-player). The shared mime database
provides generic information like name, comment and icon.
Device-specific information is available e.g. in hal and is beyond the
scope of what is proposed here.

A number of GNOME applications have been patched to include support for
content types in their desktop files; this is done simply by adding the
x-content/* type to the MimeType field in the desktop entry file;
examples can be found in this bug
http://bugzilla.gnome.org/show_bug.cgi?id=510319 and it's dependents.

To associate content types with volumes, nautilus use a number of
information sources: 

Out-of-band information can lead to tagging a device/medium with a
x-content/* type; for example if we know (due to vendor/product hardware
identifiers) that a given device is also an audio player then it's fine
to tag it with x-content/audio-player and x-content/video-player. 

Some media don't have content per se (e.g. blank discs and audio
discs); these needs to be tagged manually using more knowledge about the
device/medium.

But if the medum has content, nautilus looks at it to determine a
suitable content type. Currently, it uses a hardcoded set of tests,
which mostly look like this:

Does it contain a nonempty directory named 'dcim' or 'DCIM' ? 
    --> Digital Photos
Does it have an executable file named '.autorun' or 'autorun.sh' or
'autorun.exe' ?
    --> 'Software CD'
Etc

It would be very useful to replace these hardcoded tests with a generic
pattern language for matching trees. This would allow e.g.

- other file managers and programs to use the same criteria for
assigning content types.

- PackageKit to install a content type for 'servicepack cds' with the
necessary magic to make nautilus recognize such cds and do the right
thing.

- libvirt to install a content type for 'vm on a usb stick' that would
automatically start virt-manager when the usb stick is inserted. 

Concretely, I propose to add a <treemagic> element that would work
pretty similar to the existing <magic> element. It contains one or more
<treematch> elements, which can be nested. 

The <treemagic> element has an optional 'priority' attribute.

The <treematch> element has a mandatory 'path' attribute which specifies
what part of the tree it applies to, and several optional attributes
that specify the conditions that must be met. The 'type' attribute can
have the values "file", "directory" or "link". The boolean attributes
'executable' and 'non-empty' can be used to specify that a file must be
executable or a directory non-empty. The 'mimetype' attribute can be
used to specify the mimetype for the file specified by the path. The
boolean attribute 'ignore-case' can be used to specify that case should
be ignored when matching the path.

Examples:

<treemagic priority="75">
  <treematch path="dcim" type="directory" ignore-case="true"
nonempty="true"/>
</treemagic>

<treemagic>
  <treematch path=".autorun" type="file" executable="true"/>
  <treematch path="autorun" type="file" executable="true"/>
  <treematch path="autorun.sh" type="file" executable="true"/>
</treemagic>

<treemagic>
  <treematch path="BDAV" type="directory" non-empty="true">
     <treematch path="BDMV" type="directory" non-empty="true"/>
  </treematch>
</treemagic>

For caching, the proposal is to write treemagic files with a similar
structure to the magic file:

[50:x-content/image-dcf]
>"dcim"=directory,ignore-case,nonempty
1>"autorun.sh"=file,executable,application/x-shellscript

I'm attaching patches for the shared-mime-info spec, for
update-mime-database (to create treemagic files) and a standalone
implementation of tree matching using the treemagic files (this will
become part of a future g_mount_guess_content_type() function in GIO).
If these additions are accepted, I will also prepare a patch to
add the content types that are currently defined in nautilus.xml
to freedesktop.xml.

Comments ? 

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: contenttype-spec.patch
Type: text/x-patch
Size: 5258 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080611/1deecd2c/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: treemagic.patch
Type: text/x-patch
Size: 9939 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080611/1deecd2c/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sniff-content-type.c
Type: text/x-csrc
Size: 11321 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080611/1deecd2c/attachment-0001.c 