User Model for Filesystems Extension

$Revision: 1.1.1.1 $
Changes: available in CVS

Abstract:

This document describes the user model used in the new architecture and addresses solution to problems described in the index page. It discusses the general architecture first and after that adds few use cases to make it easier to understand the desired usage scenarios.

Content

• The model
  • MimeType usage
  • Hiding files in the explorer
  • Extensibility of features and actions
• Use cases
  • Switching between vendors
  • Customization

The model

MimeType usage

The whole system shall be designed around the notion of MimeType. Each resource in the system shall have its mime type (text/plain, text/html, etc.) associated and this value will serve for more optimal identification of the actual owner handling the resource.

The modules installed into the system shall be able to plugin their own Mime Type recognizers and some kind of customization should be available also for experienced users (map some extension to mime type, see customization use case).

The filesystems part will associate the mime type information with each resource it provides and make it available to the above system to allow it to do correct decisions.

Hiding files in the explorer

Both the user and the module writer has to be able to hide certain files in the explorer view. This shall be primarily based on the file extension. MIME type can be used as the identification for the file type since it is more granular than plain extension mechanism.

Extensibility of features and actions

Module writers will be allowed to add actions to files otherwise serviced by other module. It must be possible to add actions even in case the module does not know about the other module. MIME type is a good candidate for specifying the type where a specific action is applicable.

Use cases

Switching between vendors

<PRIORITIZE comment="what is the priority of this usecase? do we really want to support this? why is not disabling of modules option? needs to be reevaluated.">
Imagine that there are two vendors providing support for some kind of resource file. Their modules do not cooperate and cannot access the same data files at once, because of danger of corrupting the user data.

The user shall be able to choose on a global level which of the vendors shall preceed the other and take care of all resources of that type. Disabling one of the modules is not an option because modules comes in bigger chunks and can provide other useful functionality.

There might be a situation where it is useful to change the vendor just on the local level - one may want to try that functionality or wants one vendor's support exactly for this one resource.

There must be a chance to change the ownership for one (or more at once) resources.
</PRIORITIZE>
 

Customization

Let's imagine that our user decides to use extension .y for all his text files. He shall be able to configure the system to recognize files of that extension as those having text/plain mime type.

On another day the user decides to add new action into the popup menu of all text files. He locates the customization place for the text files and adds the new action into the object's menu. Also he can select which one should be the default - the one to be executed when user doubleclicks on the object.