Doc-U-Lib: About


simon.hood@umist.ac.uk

This document is available on:

Introduction

Doc-U-Lib (that's Document-UMIST-Library) is an on-line document database/library/repository widget.

Issues addressed:

Like all good projects, the whole thing is platform-independent from top to bottom: the user-interface is Web-based; the code is Perl. This means that users can share no matter what their operating system persuasion.

One can:

Working versions of DocULib can be found at scallywag.iss.umist.ac.uk/doculib.html and the latest development versions are at talby.csu.umist.ac.uk/doculib.html.

Structure and Terminology (Jargon)

The docu-base/lib consists of Trees which are collections of Branches (containers/directories/folders CDFs) which are collections of Entries. Entries consist of a document in at least one format and associated keywords and a Readme. Oh, and a History.

Containers/Directories/Folders (Nodes)

Entries exist in CDFs; these are analogous to directories/folders, but have attributes such as their own Readme and fancy read/write permissions. Just about any other attributes could be added.

Entries

Each entry consists of (at least one of) a definitive version of a document, that is an editable version (i.e., one in say doc, tex, xls or xml format), and a read-only version (e.g., in PDF or PS); also: a list of keywords a Readme and a History. Keywords and Readmes can be used for searches. The History records (and makes accessible) new and old versions of entries and comments describing reasons for updates.

Versioning

One can upload new versions of an Entry. Old version of documents associated with the entry (definitive/editable, readonly and HTML) are kept and accessible through an Entry's History.

Searches

Currently one can search on the keyword attribute of Entries, the Readmes of both Branches and Entries, and the filenames. These searches may be constrained by author and by date.

Swish-e is used for Readme searches. Indexes are built overnight (for speed) based on the keywords, and/or the Readmes and/or contents of documents.

Permissions, Groups

There is a permissions system which controls read- and write-access; this operates at the container/directory/folder level. (And is therefore controlled by means of the admin-tool. One could add access-controls at the individual Entry level in principle, by adding fields in the corresponding ENTRY file, but I can't think of a good reason for adding this complexity.)

The system is modelled after the hosts.allow/hosts.deny TCP-wrappers model. Each c/d/f must have both a USERS.DENY and a USERS.ALLOW file. These look like:
    simonh RW
    iains RW
    GROUP_readonly R
and
    ALL RW
The line GROUP_readonly R means that any user in the group readonly can read (but not write) to this branch.

Entries must be one-on-a-line. Users are can be mentioned explicitly, via a group, or via "ALL"; an explicit mention overrides "ALL"; mention via a group overrides "ALL"; an explicit mention overrides a mention via a group; if ALLOW and DENY contradict eachother, DENY wins.

What if things go wrong?

Things go wrong; they do... Our current model for the universe is entropy, which at the daily level translates as: things "go wrong".

Errors are trapped where possible: error messages are given and the problem logged. Hopefully this will help if(!) bugs are found; it will also help in restoring the integrity of the database.

Admin Tool

This allows a restricted number of users to login and:

Current Status/Where is it going?

Where we are

Map Reading




About this document:

Produced from the SGML: ./_reml_grp//about.reml
On: 14/0/102 at 11:20:11
Options: reml2 -i noindex -l long -o html -p single