Doc-U-Lib: About

This document is available on:

• talby.csu
• scallywag.iss

Introduction

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

Issues addressed:

• document sharing;
• archival of documents;
• document retrieval and searching;
• access control of documents.

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:

• upload new files and new versions of existing files;
• access a history of a document: upload dates of new versions, reasons for update...
• download (read) files;
• upload editable and uneditable versions of a document (e.g., MS Word and PDF versions) --- one could extend the permissions system to allow download of PDF-only, for example;
• search on keywords, on "Readme" content and on document content --- depending on the format of the document (the latter is NYI).
• build access-control lists for documents.

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:

• create new accounts;
• create new trees and branches;
• set permissions for these;
• delete documents;

Current Status/Where is it going?

Where we are

• DocULib is being used by people involved in the Agresso/MAIS/SITS project(s).
• The Navigation Tool is stable and has been extensively used. The only known problems are actually features of Internet Explorer (and vanish with newer versions of I.E., or use of Mozilla, Galeon, etc.)
• The Admin Tool is mostly finished: the access-control list handling needs to be improved.
• A dedicated server is hopefully crystallising out of the nebula.
• The current server is backed up on a daily basis.
• DocULib is ready and available for use.

Map Reading

• Code modification to use persistent CGI (e.g., FCGI), hence faster and easier to do more tortuous things.
• Adding searching of documents (PDF, Word/.doc and postscript; Excel/.xls could cause problems...
• Could look a little more "professional"...
• Some new features would be nice: easier viewing of a whole Tree and permissions for each Branch; finish searching facilities.
• Any suggestions?