Development talk:File API: Difference between revisions
From MoodleDocs
No edit summary |
No edit summary |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
===Main tasks=== | |||
* File Storage API: | * File Storage API: | ||
** abstract | ** abstract (M1) | ||
** local pool implementation | ** local pool implementation (M1) | ||
** DB schema | ** DB schema (M1) | ||
** deletion, acls, metadata | ** deletion, acls, metadata (M1) | ||
** problem: empty directories, file overwriting | ** problem: empty directories, file overwriting | ||
* File Manager API: | * File Manager API: | ||
** unique class, able to handle one "file area" | ** unique class, able to handle one "file area" (M2) | ||
** security | ** security (M2) | ||
** js and non js implementations of FileManager | ** hack old file manager to be able to work with new fileareas (M3) | ||
** integration with editor | ** js and non js implementations of FileManager (M4) | ||
** integration with formslib | ** integration with editor (M4) | ||
** integration with repos | ** integration with formslib (M4) | ||
** integration with repos (M4) | |||
** problem: zip support | ** problem: zip support | ||
* File Serving: | * File Serving: | ||
| Line 19: | Line 21: | ||
*** draftfile.php | *** draftfile.php | ||
*** userfile.php | *** userfile.php | ||
* from other moddata places: | ** from other moddata places: | ||
*** rssfile.php | *** rssfile.php | ||
*** user/pix.php | *** user/pix.php | ||
*** user/pixgroup.php | *** user/pixgroup.php | ||
* Migration: | * Migration: | ||
** course files (as much as possible, allow fallback) | ** course files (as much as possible, allow fallback) (M2) | ||
** moddata | ** moddata | ||
** | ** | ||
* Backup & restore: | * 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? | |||
== meta information == | |||
It seems like it would be nice to include some meta information about certain file types, e.g.: | |||
* images: width, height, alt | |||
* flash files: width, height | |||
Regarding: [[Development:File_API#Files_database_tables]] | |||
::Perhaps we could also hash filepath and filename and index by them, to save some text limitations in the DB side (length limits of indexes, not indexable, complex retrieval...). [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 11:54, 29 June 2008 (CDT) | |||
::Also, perhaps we should store finally the plugin type there to save some queries per request, using it to drive to the correct file handling of each plugin. [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 18:54, 29 June 2008 (CDT) | |||
Latest revision as of 06:26, 2 February 2009
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
- from pool:
- 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?
meta information
It seems like it would be nice to include some meta information about certain file types, e.g.:
- images: width, height, alt
- flash files: width, height
Regarding: Development:File_API#Files_database_tables
- Perhaps we could also hash filepath and filename and index by them, to save some text limitations in the DB side (length limits of indexes, not indexable, complex retrieval...). Eloy Lafuente (stronk7) 11:54, 29 June 2008 (CDT)
- Also, perhaps we should store finally the plugin type there to save some queries per request, using it to drive to the correct file handling of each plugin. Eloy Lafuente (stronk7) 18:54, 29 June 2008 (CDT)
