Revision as of 18:16, 18 February 2011

content management for MeeGo

This page captures the stream of thoughts related to ways to improve content management on MeeGo.

The primary goal is to provide a responsive user experience for applications which are consuming content. This means that content must be inspected and had meta data extracted from it (including thumbnails) prior to the application requesting the content. A consequence of that requirement means that on-the-fly indexing is a dead end as you can not guarantee that indexing will be complete when the application is launched.

The best time to perform the indexing and scanning of content is at the time of content acquisition; the user is already expecting to wait for content to copy/save to the system--a minor delay in an already anticipated delay is much better than a delay at a time when the user does not expect a delay.

A side benefit of performing index-at-acquisition is that we no longer have to perform any background indexing or thumb nailing on the system -- which has frequently introduced sporadic responsiveness to the UI as the system can inadvertently lock system resources while an index is occurring.

index-at-acquisition

Since MeeGo provides a posix interface to the file system, it would be problematic to enforce a requirement that all applications use a specific API for reading and writing to the content storage locations. An alternative approach is to use a file system in user space (FUSE). The FUSE file system would be mounted to the various locations in the user's home directory where content must be placed for it to be accessible from the content management applications.

The FUSE implementation would block the final close of a file within the mounted file system until indexing, thumb nailing, and meta data extraction is complete. A benefit to this approach is that the content being written to disk is (in most cases) present in RAM and more easily accessed for whatever processing is required. This means that in addition to the benefits already mentioned, the cost of indexing and thumb nailing at index-at-acquisition time is less than the cost of on-demand/on-the-fly indexing.

Photos

Thumb nailing of photos will occur at the time of acquisition, as outlined above. The specific thumbnails generated by the FUSE are as follows:

• Thumbnail for view in photo viewer -- size is target display density dependent, based on intended physical size of thumbnail. Two thumbnails are generated, one for each orientation. Enhanced functionality to ensure that regions-of-interest (ROI) are placed into the thumbnail may be employed via manual or automatic detection (for example, auto-center of detected faces, 5:3 ratio split rules for high contrast/line detection, etc.)
• Target display resolution scaled image -- used for "full screen" mode
• Full resolution image -- asynchronously used for "zoom" mode and kept as the original image source, unmodified

locations on disk

The following locations are subject to index-at-acquisition:
${HOME}/Pictures
${HOME}/Videos
${HOME}/Music
${HOME}/Downloads

database ontologies

tbd

MeeGo APIs for accessing content and data

tbd

FUSE implementation details

tbd