This documentation discusses interfaces and classes for Pincette modules and WebDAV-client developers.

See:
Description

Packages

be.re.net
be.re.repo	Here you will find all module interface definitions.
be.re.repo.mod	This package contains some utilities that are helpful for certain document formats.
be.re.webdav
be.re.xml
be.re.xml.stax

This documentation discusses interfaces and classes for Pincette modules and WebDAV-client developers.

In Pincette a number of parts are configurable through modules. These implement certain interfaces and are placed in the /configuration/ folder. The /configuration/maps.xml contains the declarations of the modules. Such declarations can apply either for certain WebDAV-collections and everything below or for the entire repositiory. Certain declarations may also depend on specific MIME types.

Modules are always deployed in their own class loader, which isolates them from each other. This way different modules can use different versions of certain packages without interference, making release management a lot easier. Modules can refer to other packages through their manifest file's class path, which contains relative URLs to them. In practice this means that when a module uses a package you can just place it next to it under the /configuration/ folder or wherever the manifest expects it to be.

The /configuration/ folder is under supervision of its own built-in dynamic view called /view/configuration/. Since views can use labels as a version selection mechanism, easy configuration management is possible for the configuration area as a whole. It allows you to keep track of all changes, just like with any other document or folder in the system. When the latest configuration version doesn't work as expected you can fall back to the previous one by just setting its label in the dynamic view. Whenever the slightest part under the /configuration/ folder changes because of a different version selection, the whole configuration is reloaded. Failing to load a configuration leaves the current one running.

Modules can be created for the following tasks:

• Document comparison: this is used when the header X-be.re.Compare-With is set on the HTTP method GET. This is a Pincette extension.
• Meta-data exchange: the meta-data in a document can be extracted and used in the system and changes of meta-data in the system can cause updates in the documents.
• Merging of versions: Pincette supports branch and merge in its versioning system. The required knowlegde about specific document formats can be conveyed in a module. The default merge module just copies the source version to the target version.
• Storage: the physical byte stream of a document in the database is determined by a module.
• In transformations: those are transformations on documents that are performed on-the-fly when they are saved into the system. A document can even be transformed from one MIME type to another.
• Out transformations: those are transformations on documents that are performed on-the-fly when they are retrieved from the system. A document can even be transformed from one MIME type to another.
• Testing differences: modules that can say for a particular format whether two versions are different or not, without calculating what those differences are.
• Text extraction: extract the text from a document for the full-text indexer. The system uses this when searching for potential version mergers.
• Preview extraction: create a preview from a document. The system will derive three standard sizes from it, which can be used in various contexts.

Most module interfaces have special variants for XML, because XML-documents get special treatment in Pincette.

Modules can perform actions against the server they sit in as if they were a client of the server. They have to use a special constructor of the be.re.webdav.Client class, which causes a direct dispatch into the server instead of going via HTTP. However, the same marshalling, validations and security checks apply. A module normally runs in the security context of the user that performed the request. This is not to shield the system from the modules, which are trusted code, but it is merely for the convenience of module implementators so that the correct security context is propagated automatically. A system module could easily use the system security context.