Repository API

This page describes the specification for a future feature, currently being worked on for Moodle 2.0. This spec is STILL UNDER CONSTRUCTION.

Overview

The Repository API is a core set of interfaces that all Moodle code will/should use so that we can easily read files from all kinds of external document repository systems.

It's important to remember that a repository is generally treated as READ-ONLY. Management of the files is done through the native interface provided by the repository. Publishing of files to a repository is handled by the Portfolio API.

A typical user story:

1. User wants to add a new resource to a course
2. User clicks the "Choose a resource" button
3. User is able to choose from a list of configured repositories (this step will be skipped if there's only one).
4. User is presented with a simple file picker to choose a document
5. User chooses a document
6. Document is COPIED into Moodle and included in the course.

When selecting the document, the user may have options to

• only return the URL to the file if it's desired to keep it external (but this does present security and integrity risks), or
• refresh the local file copy regularly and automatically

Architecture

All file-handling areas in Moodle (eg adding a new resource, adding attachments to a forum post, uploading assignments) will be rewritten to talk to the standard API class API methods in a standard way.

Each repository plugin (a standard Moodle plugin stored under /repository/xxx) will subclass the standard API and override methods specific to that repository.

As is usual in Moodle, there will be admin settings to disable/enable certain repository plugins as standard, as well as user settings so that users can add their own personal repositories to the standard list (eg Yahoo Briefcase or Google Docs) and to select their default repository.

Note that the current default file manager in Moodle will also be rewritten as a repository plugin.

Repository requirements

From the Moodle point of view, each repository is just a hierarchy of nodes.

The repository MUST provide:

1. A list of the nodes (eg files and directories) under a given node (eg directory)
2. A URL to download each node (eg file).

The repository can OPTIONALLY:

1. Require some authentication credentials
2. Provide more metadata about each node (mime type, size, dates, related files, dublin core stuff, etc)
3. Describe a search facility (so that Moodle can construct a search form)
4. Provide copyright and usage rules (or just information about the rules)

Repository plugins

Some plugins I'd like to see developed for the first version are:

• files - very similar to the current course-based file manager
• moodle - an interface to another Moodle site, accessed over a secure mnet connection
• jsr170 - an interface that can talk to anything that supports js170 (eg Alfresco)
• oki - an OKI emulator allowing us to access things with OKI interfaces,like Fedora
• briefcase - an interface to Yahoo Briefcase
• myspace - an interface to MySpace files
• googledocs - an interface to Google Docs
• skydrive - an interface to Microsoft's SkyDrive files
• facebook - an interface to Facebook files
• merlot - an interface to the learning materials in Merlot.org
• flickr - an interface to flickr
• youtube - an interface to YouTube
• mahara - an interface to a Mahara installation

Class methods

Under construction