Improved support for external File content: Difference between revisions
From MoodleDocs
(Created page with "==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 s...") |
|||
Line 15: | Line 15: | ||
## pluginfile.php calls a file logging subsystem to log the fact that this file is being served (useful for copyright reporting, for example) | ## pluginfile.php calls a file logging subsystem to log the fact that this file is being served (useful for copyright reporting, for example) | ||
## (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 | ## (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 | ||
# 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: | |||
## Garbage cleanups | |||
## 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. | Note that the original URL of files in external repositories are never revealed to users. | ||
==Details== | ==Details== |
Revision as of 07:41, 18 August 2011
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
- 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.
- 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).
- Improve the filesystem repository plugin to make it easier to create folder repositories on the fly
- Add support to the filepicker UI to add "linking" to more repositories that support it, including the server files and filesystem browser.
- Virtual files are served via pluginfile.php URLs just like normal files:
- pluginfile.php uses module callback to determine access, and if it passes then
- pluginfile.php calls a file logging subsystem to log the fact that this file is being served (useful for copyright reporting, for example)
- (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
- 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:
- Garbage cleanups
- 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.