BFS2 or our next FS

Possible Candidates

• ZFS (very cool, snapshots, volume chaining (no more partition management...), interesting for query-only FS, compatible license)
• XFS (fast, proven, effective)
• roll our own (much work)

Extended File Type System

File types become more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (OGG would inherit from Audio and Video, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the super type (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.

Hard-Link

The next file system should support hard-links and hard-link attributes for which you can choose the desired file type of the target in the attribute's specification.

Extended-Link and File IDs

Every file gets a unique ID that does not change when it is moved (unlike the inode). An extended link consists of a volume ID and such a file ID. It is similar to a hard-link, but without increasing the target's reference count. Extended-link attributes can have a desired target file type in the attribute's specification.

Multi-Value Attributes

Attributes are allowed to have more than just one value. For instance, a contact may have multiple email addresses.

Ranges

Sometimes one might want to define a range of possible values for a value (most appropriately an integer or other numeric type). For example:

• percentage (task accomplished)
• rating (music)

Enumerators

Enumerators are 64-bits values which represent one of a defined set of string values. The 64bit value should where possible be the UTF-8 representation of the value, or as close as possible for interest of human readability. Users should be allowed to add their own values to an enumerator.

Extensions

An extension allows for adding a collection of additional attributes to a file or folder (as if it had inherited the attributes of multiple file types). You can add any number of extensions independent of the file's type. Internally, a multi-value attribute stores which extensions are used by a file.

Virtual Attribute Groupers

Sometimes you want to have the values of multiple attributes collected into one attribute. Take email recipients as an example. Instead of accessing "To", "Cc", and "Bcc" individually, when creating a query or when categorizing files, you use "Recipients". This attribute does not really exist on the volume, but is generated to simplify attribute handling.

Actions

Each application says which actions it can perform on a given file type. BeMail would say that it can do the following (optional arguments are in brackets):

• "Reply to" "Email"
• "Write Email" (to "Person")
• "Forward" "Email" (to "Person")
• "Send as Attachment" any type (to "Person")
• default: "Read" "Email"

These actions can be executed from within Tracker and supporting applications.

Categorization

The contents of folders and files can be categorized and subcategorized by attributes. This facilitates categorizing a query for "Audio" files by "Genre" and one level deeper by "Artist", for example. The root category "All" should still be shown in case the user wants to work with all matching files.