There are lots of good reasons that files should be nodes. Derivates is one such reason, where you have an original file, and then things like different sizes and/or formats (think the HTML version of a Word doc).
For really scaleable file system usage, files need to be just files. And ideally served off a different server optimized for static files.
The File API needs to easily expose functions that handle both. Currently, it doesn't handle storage at all. It should implement some default storage types and actually make it easy to work with files. From talking to all people doing stuff with files, it actually just makes it harder to deal with files.
I mean that FileAPI should do some default storage that keeps file/DB stuff in sync. As James always says, upload module's table should be renamed to upload table, since it's the only module that actually keeps stuff there....
Other modules should be able to use the same FileAPI methods, but implement different storage types (e.g. "remote" file storage).
But at some point James will come along and say it in a more developer-y way that will be less about me talking out my ass.
// Copy a file managed by Drupal/FileAPI.
function file_copy($file, $dest) {
if (_file_copy($file, $dest)) {
$file->filepath = $dest;
$file->filename = basename($dest);
if (db_query('INSERT INTO {files} ...')) {
return $file;
}
else {
_file_delete($file);
}
}
return false;
}
// Copy a file with out updating the Drupal Files tables.
function _file_copy($file, $dest) {
// Select a storage handler based on file and system settings
$storage_handler = _file_get_handler($file);
$callback = $storage_handler.'_file_copy'
if (function_exists($callback)) {
return call_user_func($callback, $file, $dest);
}
return false;
}
where the functions beginning with _ do the file system level activity and shoudl be considered private functions of the file_api, but can still be used by the daring to expose the storage handlers, and the normal functions provide file_system level handling and database handling....
Comments
Both
There are lots of good reasons that files should be nodes. Derivates is one such reason, where you have an original file, and then things like different sizes and/or formats (think the HTML version of a Word doc).
For really scaleable file system usage, files need to be just files. And ideally served off a different server optimized for static files.
The File API needs to easily expose functions that handle both. Currently, it doesn't handle storage at all. It should implement some default storage types and actually make it easy to work with files. From talking to all people doing stuff with files, it actually just makes it harder to deal with files.
I completely agree....
When you say the FileAPI should handle storage what do you mean?
I agree its hard to deal with, and you have to keep files and db's in sync on your own... Its a real pain.
Default storage
I mean that FileAPI should do some default storage that keeps file/DB stuff in sync. As James always says, upload module's table should be renamed to upload table, since it's the only module that actually keeps stuff there....
Other modules should be able to use the same FileAPI methods, but implement different storage types (e.g. "remote" file storage).
But at some point James will come along and say it in a more developer-y way that will be less about me talking out my ass.
possible file_copy example
ok I think I get the idea...
Something like:
// Copy a file managed by Drupal/FileAPI. function file_copy($file, $dest) { if (_file_copy($file, $dest)) { $file->filepath = $dest; $file->filename = basename($dest); if (db_query('INSERT INTO {files} ...')) { return $file; } else { _file_delete($file); } } return false; } // Copy a file with out updating the Drupal Files tables. function _file_copy($file, $dest) { // Select a storage handler based on file and system settings $storage_handler = _file_get_handler($file); $callback = $storage_handler.'_file_copy' if (function_exists($callback)) { return call_user_func($callback, $file, $dest); } return false; }where the functions beginning with _ do the file system level activity and shoudl be considered private functions of the file_api, but can still be used by the daring to expose the storage handlers, and the normal functions provide file_system level handling and database handling....
Does that sound like the idea?
}
nodes not mandatory?
I voted for nodes. But can I qualify by saying that I get quesy about the idea that all files should have to be nodes. :-)