|
Home · All Classes · Annotated · Functions | |
The Document Server maintains the document meta-information database and provides synchronized Content list models. It handles requests for document services such as delete, rename and open. The following sections describe the functionality of the Document Server together with key criteria for optimum implementation.
Performance is a key criterion, especially where large numbers of files are processed. When inserting a large capacity removable media and scanning file systems to extract Content metadata the document server does not schedule blocking reads in the GUI thread. This means that scanning is done incrementally thus, reducing the impact on GUI response.
Metadata records are stored in an embedded SQL database. The database backing store is in the main storage on the device, not on removable media. A server process monitors changes in storage and updates the SQL database as required.
The database schema is as follows:
| ContentTable | ||
|---|---|---|
| Field | Type | Details/Index |
| id | int | autoincrement unique key |
| uiName | varchar 100 | indexed |
| mimeType | varchar 50 | indexed |
| size | int | |
| drmStatus | enum one of: plain controlled unrenderable | |
| docStatus | enum one of: doc dat | indexed |
| icon | blob (binary large object) | |
| thumbnail | blob | |
| owner | int | index (foreign key) |
| CategoryMapTable | ||
|---|---|---|
| Field | Type | Details/Index |
| contentId | int | foreign key ContentTable |
| category | int | foreign key Categories |
Note:
A process running inside the Qtopia server is responsible for keeping the database view synchronized with the files and content on the device. This is the Data Update Process (DUP).
When new content arrives on the device either by download, Bluetooth transfer or insertion of media records, it will be added or refreshed in the database. When content is no longer on the device due to removal of media, or deletion of files, these are deleted from the database.
When new media is inserted the DUP also checks it for metadata in import-format. The DUP ensures that any metadata is correct and up-to-date with respect to the actual content on the media, and automatically imports it.
After that point calls to the ContentLnk API to change the files will result in updates to the import-format metadata. The DUP is not required to perform those updates.
If QtopiaDesktop is used to mirror the device as is the case when PIM contacts and other data are synchronized, the metadata, especially categorization information, can be transferred via a database synchronization. This is done by replaying the journal files from the point at which the last synchronization took place. Journal files are normally recorded automatically by the database system.
When data is transferred other than by a synchronization, for example:
the metadata must be translated into an import format on one side of the transfer and translated back on the other side.
In the case of category data additional information, such as a device specifier has to be added to disambiguate the categories from top-level name collisions if there is more than one Qtopia device.
The Qtopia metadata import format (QDIF) files are XML and are essentially serialized from the database and have a device identifier embedded in them.
| Copyright © 2006 Trolltech | Trademarks | Qtopia 4.1.7 |