Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Improved support for external File content: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 1: Line 1:
{{Work in progress}}
{{Infobox Project
|name = File synching
|state = Planning
|tracker = TODO
|discussion = TODO
|assignee = [[User:Martin Dougiamas|Martin Dougiamas]]
}}
{{Moodle 2.2}}
==Problems with Files in 2.0==
==Problems with Files in 2.0==



Revision as of 06:38, 24 August 2011

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

File synching
Project state Planning
Tracker issue TODO
Discussion TODO
Assignee Martin Dougiamas

Moodle 2.2


Problems with Files in 2.0

  • It is not currently easy to use a file in multiple places throughout Moodle and update them all at once
  • It is not currently easy to create a simple shared "course repository" for teachers to use


Proposed solution summary

The basic idea is to allow the CONTENT of files to be stored outside of the filepool, while all the metadata and access is controlled by Moodle exactly the same as it is now.

  1. Extend Files API with a new "location" concept, with all files now having a "locationrepository" and a "locationreference", which defines where the content of the file is.
  2. All files copied into Moodle have a "locationrepository" of "local", but others will specify a UUID (usually a URL with file-specific tokens in it, created by the original user who placed the file).
  3. Improve the filesystem repository plugin to make it easier to create folder repositories on the fly
  4. Add support to the filepicker UI to add "linking" to more repositories that support it, including the server files and filesystem browser.
  5. Virtual files are served via pluginfile.php URLs just like normal files:
    1. pluginfile.php uses module callback to determine access, and if it passes then
    2. pluginfile.php calls a file logging subsystem to log the fact that this file is being served (useful for copyright reporting, for example)
    3. (virtual files only) pluginfile.php uses repository callback to get the content of the file, and streams it to the user with appropriate mimetypes etc
  6. When a file is linked to another another file in the local location, then it has a location of "filepool". We need to pay attention to these during:
    1. Garbage cleanups
    2. Deleting the original file should create real copies of that file where required (user informed).

Note that the original URL of files in external repositories are never revealed to users.

Details