Repository API
Repository Application Programming Interface (API) is a group of functions that work with Java. The development aim is to make Moodle flexible enough to link to any repository of these functions so that Moodle users can use them to find files for use in Moodle, as well as storing their own documents there.
To do this we will implement a layer in Moodle that takes care of the details, so that as far as Moodle modules are concerned there is just a single coherent "File system".
Major Tasks
Create Repository API
API is basically a class library of functions that expose the Java Service Request (JSR)-170 functionality. For example, there will be simple functions like get_file(), search_files(), insert_file() etc (not actual names) as well as more detailed functions for handling versions, metadata etc.
Plugins will extend this class, overriding certain functions with local implementations of that functionality. Plugins will also publish information about what functionality they support. For example, some repositories may be read-only, so everything to do with writing needs to be disabled in the interface.
Create File-based Repository Plugin
This simple plugin will implement as much as needed to replicate the functionality that we have now (with the exception that data is not course-based any longer).
Create JSR-170 Repository Plugin
This simple plugin really just "passes through" commands between Moodle and an external JSR-170 compliant repository (eg Jackrabbit or Alfresco).
Convert Moodle code to use the API
Basically, wherever Moodle reads/writes files the code needs to be converted to use the repository API instead. Some of the hardest work will be in the area of Roles and Permissions.
Build Admin interface
The admin interface allows the admin to add new repositories and set them up for use in Moodle. The admin may also decide which people can see certain repositories based on Role.
Build new user interfaces
Wherever people deal with files (resources, forum attachments etc) they need a "file picker" to let them select and interact with the repository. This file picker needs to then pass back information to the context where it was called (eg pass the path of a file back to the resource-adding page).
If there is only one repository configured, then the interface just shows actions possible with that repository. If there is more than one repository then the user sees a menu in the picker to switch their "current" repository.
Outstanding issues
Access controls
How is it controlled who can see what in the repository? At the moment there is some basic access controls. There are site files, which anyone can see, and course files, which only people enrolled in a course can see, and user files, which belong to a particular user. Then in those various categories, there are files that all roles can see, and ones (e.g. backup files) that only teachers can see.
So what I am saying, is that how do Moodle Roles and capabilities correspond to access restrictions enforced by the repository. Suppose there is a file in the repository that only a teacher can access. How can we stop the teach adding that image to a page of Moodle content, which will just leave the student seeing a broken image icon because they don't have access to that image?
Is it possible to use the same model that the 1.9 question bank does, where a resource is ascribed to a context level? Matt Gibson 06:43, 3 October 2007 (CDT)
