1.1 --- a/docs/wiki/Mechanisms Fri Mar 25 01:20:33 2022 +0100
1.2 +++ b/docs/wiki/Mechanisms Fri Mar 25 01:42:15 2022 +0100
1.3 @@ -124,8 +124,8 @@
1.4
1.5 == Resources ==
1.6
1.7 -Resources allow each user of a filesystem object to access that object
1.8 -independently. They effectively provide a session in which accesses may occur.
1.9 +Resources are objects accessed by clients that support a basic level of
1.10 +accounting and management.
1.11
1.12 The base interface of a resource is as follows:
1.13
1.14 @@ -139,23 +139,37 @@
1.15
1.16 In practice, other operations are required to make resources useful.
1.17
1.18 +In some cases, resources provide the mechanism by which each user of a
1.19 +filesystem object may access that object independently. They would then
1.20 +effectively provide a session in which accesses can occur.
1.21 +
1.22 === Directory Resources ===
1.23
1.24 Directory resources primarily expose the contents of directories in the
1.25 -filesystem. They employ directory accessors which concern themselves with the
1.26 -actual filesystem content.
1.27 +filesystem to a user. They employ directory accessors which concern themselves
1.28 +with the actual filesystem content.
1.29
1.30 [[Components#Directories|Directory components]] are provided using directory
1.31 resources.
1.32
1.33 -=== Pagers ===
1.34 +=== Pagers or File Resources ===
1.35
1.36 Pagers are resources that support dataspace access operations, thus allowing
1.37 -the resources to expose filesystem content in mapped memory regions.
1.38 +the resources to expose filesystem content in mapped memory regions to a
1.39 +particular user of the object providing the content.
1.40
1.41 [[Components#Files|File components]] and [[Components#Pipes|pipe components]]
1.42 are provided using pagers.
1.43
1.44 +=== Filesystem Resources ===
1.45 +
1.46 +Filesystem resources provide the entry point for access to a filesystem by
1.47 +other components or programs. Since filesystems often enforce identity-based
1.48 +access controls, a filesystem resource will typically support the
1.49 +`open_for_user` operation in various forms, with the result of this operation
1.50 +being the instantiation of an `OpenerResource` configured for the indicated
1.51 +user identity.
1.52 +
1.53 == Registries ==
1.54
1.55 The basic mechanism for obtaining a resource involves a registry, as
1.56 @@ -242,4 +256,7 @@
1.57 However, the chosen approach is to permit `OpenerResource` objects to
1.58 implement the `FileOpening` interface for each filesystem, meaning that the
1.59 `ResourceRegistry` will end up being called by the opener and then invoking
1.60 -the opener in return.
1.61 +the opener in return. This is slightly more convenient than the alternative
1.62 +since the opener can be configured with a given user identity, and such
1.63 +identity details will ultimately be employed when accessing the underlying
1.64 +filesystem itself.