This is a test site. Any changes will be lost!

Development talk:File API: Difference between revisions

From MoodleDocs
No edit summary
 
(192 intermediate revisions by 9 users not shown)
Line 1: Line 1:
Some quick questions to avoid forgetting them:
===Main tasks===
* File Storage API:
** abstract (M1)
** local pool implementation (M1)
** DB schema (M1)
** deletion, acls, metadata (M1)
** problem: empty directories, file overwriting
* File Manager API:
** unique class, able to handle one "file area" (M2)
** security (M2)
** hack old file manager to be able to work with new fileareas (M3)
** js and non js implementations of FileManager (M4)
** integration with editor (M4)
** integration with formslib (M4)
** integration with repos (M4)
** problem: zip support
* File Serving:
** from pool:
*** file.php
*** pluginfile.php
*** draftfile.php
*** userfile.php
** from other moddata places:
*** rssfile.php
*** user/pix.php
*** user/pixgroup.php
* Migration:
** course files (as much as possible, allow fallback) (M2)
** moddata
**
* Backup & restore:


1) Will them be under the control of FileAPI?
===Milestones===
M1: File storage API completed (this week)
M2: migration of course files + new filephp + FileManager + hacked old file manager (next monday)
M3: ...


- dataroot/temp
- dataroot/lang
- dataroot/cache
- dataroot/environment
- dataroot/filter
- dataroot/rss
- dataroot/search
- dataroot/sessions
- dataroot/upgradelogs


2) Assuming we'll have a cool OOP FileAPI...


- a) Will it support different FileAPI classes (to be able to store in other systems) ?
===rssfile.php===
- b) Will it support multiple FileAPI classes working together (like the Repo) ?
It's said that rss/file.php is kept only for backwards compatibility. But what exactly is meant by "backwards compatibility"?  
 
Just display feeds with nice error messages and info how to re-subscribe?
3) I've annotated in red some things that have sounded strange in my first look.
 
4) Are we going to have "directory records" in the implementation, or that is going to be handled exclusively by the "moodlepath" column?
 
5) One general question... are we going to "force" all modules to be "autocontained" ? How are we going to handle resources, for example (with all those css, links, images..). In general how are we going to handle multiple-file packages?
 
That's all for now, ciao4niao :-) [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 21:27, 5 April 2008 (CDT)

Latest revision as of 21:02, 26 July 2008

Main tasks

  • File Storage API:
    • abstract (M1)
    • local pool implementation (M1)
    • DB schema (M1)
    • deletion, acls, metadata (M1)
    • problem: empty directories, file overwriting
  • File Manager API:
    • unique class, able to handle one "file area" (M2)
    • security (M2)
    • hack old file manager to be able to work with new fileareas (M3)
    • js and non js implementations of FileManager (M4)
    • integration with editor (M4)
    • integration with formslib (M4)
    • integration with repos (M4)
    • problem: zip support
  • File Serving:
    • from pool:
      • file.php
      • pluginfile.php
      • draftfile.php
      • userfile.php
    • from other moddata places:
      • rssfile.php
      • user/pix.php
      • user/pixgroup.php
  • Migration:
    • course files (as much as possible, allow fallback) (M2)
    • moddata
  • Backup & restore:

Milestones

M1: File storage API completed (this week) M2: migration of course files + new filephp + FileManager + hacked old file manager (next monday) M3: ...


rssfile.php

It's said that rss/file.php is kept only for backwards compatibility. But what exactly is meant by "backwards compatibility"? Just display feeds with nice error messages and info how to re-subscribe?