Developing Modules for the Sharity Framework

Foundation:

The foundation can be seen as an extension of the programming language. It provides such basic functionality as container datatypes, operating system abstraction and the eventloop. All modules build on the services provided by the foundation. The foundation itself does not rely on services provided by any other module. No arrows have been drawn towards the foundation block in the above illustration because all modules call it and the large amount of arrwos would obscure the image.

Main Module/Framework:

The framework builds a wrapper around all other modules. It contains other foundation-like functions that are more specific for the needs of Sharity and it contains the main()-function that loads and initializes the other modules. Most of the user interface communication is handled by the main framework, too. You should look at the file module.h in the directory mainFramework to learn about the internal representation of a module.

Frontend:

The frontend is the module that actually gets the information into the operating system's file space. It may use whatever technique it likes to provide this service. The basic frontend provided with Sharity is the nfs2 module, which uses NFS version 2 to provide the service. Modules based on NFS version 3 or a direct interface to the kernel's virtual filesystem are also possible. The frontend has to cope with peculiarities of the unterlying techniques, such as providing unique NFS file handles for NFS based frontends. The frontend provides an object oriented interface centered around a mountpoint representation object. It holds a reference to one backend module and it's object instances. All file accesses are converted to the backend interface and routed through to the backend. See the file frontend.h in the mainFramework directory for the exact interface of the module and a description of the functions.

Backend:

The backend module actually provides the data that should be seen below the mountpoint. It has an object oriented interface based on three classes: The data source object itself, one class to represent authenticated users and one class to represent files and directories. For more details about the interface definition please see the file backend.h in the mainFramework directory. Sharity currently comes with three backend modules: dummyFs, which is the minimum possible backend which serves as a short demonstration example, cifsFile, which can be used to mount CIFS/SMB shares from Windows machines and cifsBrowse which is an automounter which maps the available resources (in terms of available servers and exported shares) into the filesystem space.

UI Application:

The user interface application is responsible for all communication with the user. It is connected to the Sharity daemon through an RPC interface which runs over a Unix domain socket. The UI application builds on RPC functions provided by the various modules. Each module can have it's own set of RPC functions which can be called by specialized UI applications. However, this procedure is strongly discouraged. The main module and it's associated user interface functions provide a mechanism for generic user interfaces that can be used by any module. The GUI is described by structures and built from this description automatically. Commandline tools may have to know more about the context of interactions and may therefore require specialized RPC calls.

Interaction of Modules shown for the nfs2 and cifsFile Modules