User Model for Filesystems Extension
$Revision: 1.2 $
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
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.
