Targets, requirements, functional discription

This chapter contains all the requirements (what should it do), functional descriptions (what does what) and the targets (what we watn to achieve). Please log in to edit, this is a first draft.

Requirements

  • Any module should be able to use the uploads with any node (any node can contain an audio file)
  • A module should be able to carry a dedicated uplaod with a private node (node type audio can only contain audio files)
  • Any module can override the upload fields (image module might want to replace teh word ‘file’ with ‘image’)
  • Any module can add items to the upload fields (image module might want an extra ‘thumbnail upload’ field to override thunmbnails)
  • A custom node type can require an exact number of uploads. (I.e. a multimedia lesson type could require one video, one image, and 2 flash files).
  • Upload module will announce its file, on upload, to all modules via a hook. They can then use the mime or other field to decide if they want to modify the file
  • Upload module will announce its file, on download, to all modules via a hook. They can then use the mime or other field to decide if they want to modify the file, or trigger some event
  • On download, a module may deny access to the requested file.
  • Upload module will announce its file, on a cron run, to all modules via a hook. They can then use the mime or other field to decide if they want to modify the file, or trigger some event
  • Any module can add information and settings to the uplod configuration page

Targets

  • Make uplaod a general upload centre
  • Make the file system modular, so other modules can reuse its features.
  • Make suer all modules are aware of eachothers files on three events: uplaod, cron and download (aka view)

Functional descriptions

  • $files[$fid] is an array that contains files objects
  • Each file object contains:
    • filename
    • path
    • source: I don’t know why this is there now.
    • filemime
    • filesize
    • oid (node id, comment id, any object id)
    • vid (version id, for revisions)
    • inline (can the file be shown inline)
    • show (do we/user allow the file to show, now called “list”)
    • object_type (node, comment, term, user)
    • …
    • data (specific data, like ID3 tags, exif info, PDF metadata etc)
      • …
      • …
      • …
      • …
  • fileapi($file) (an api, modelled after nodeapi)
    • form: alter or add items to the uplaod form
    • validate: a file is uploaded, validate it
    • insert: a file is inserted/uploaded
    • delete: a file is deleted
    • cron: a cron is ran
    • download: a download is called (or a file is viewed outside of the page)
    • view: a file is viewed inline
    • settings: add stuff to the upload settings page. hook should retulrn a Form array. To modify the default form, just return a modified $form[‘settings_genera’]
  • file.inc calls file.protocol.description.inc, based on:
    • the stored ‘path’ in the files table
  • file.protocol.description.inc contains all the tough work, optimised for that file storage protocol. it is build up as:
    • file.protocol.description.inc: indicates its part of the file API
    • file.filemethod.description.inc: the method for storing. The path of the files in the files table contains the method too. Examples are:
      • file:// (file.file.unix.inc) local storage
      • http:// (file.http.remote.inc) a file on another site
      • mysql:// (file.mysql.database.inc) a file stored as binary in the database
      • smb:// (file.smb.database.inc) a file on a samba network share
      • yniip:// (file.yniip.database.inc) you name it, its possible
    • file.filemethod.description.inc: this is only there to be able to differentiate between various include files with the same method. An example is the difference between file.file.unix.inc and file.file.windows.inc. Another dialect could be file.file.peruser.inc wich stores files in directories like /files/1123/ for user 1123
  • To start, we have two methods: file.file.unix.inc and file.file.windows.inc
  • if someone volunteers we will have a file.http.remote.inc
  • The file.incs must support a range of API functions:
    • file_delete($file): removes the file from the FS
    • file_save($file, $file->filename): Save the file on the FS
    • file_check_uplaod($file): check if an uploaded file exists on the FS
    • file_copy: copies the file
    • file_move: moves the file
    • file_info: gives information about the file
‹ Presentation drupal in files communitiesupTodo list ›
categories:

File Locks and Inline Viewing

Submitted by sun@drupal.org on Wed, 05/10/2006 - 08:03.

I’m not able to edit the wiki pages but I would like to add:

  • checkin/checkout (locks) of files. If a user is editing/uploading/downloading a file a module eventually wants to disable access temporarily or permanently.
  • Inline injection of files into other nodes. Current img_assist/inline modules should definitely be part of this new file handler.

I just added a couple

Submitted by yogadex@drupal.org on Sat, 10/29/2005 - 20:34.

I just added a couple requirements, but to make it more clear…

Several times I’ve created custom node types which require a collection of files. For example an online lesson which consists of a video, a fixed number of flash files, and a preview image. So when creating a node of this sort, the admin should be prompted for exactly those files, and not be presented with a generic “upload another” field.

Also, in the case of the online lessons, the preview image should be visible to all users. The other files only to paid subscribers. Except in the case of “free sample” lessons, in which all files are visible to all users. So what I’m getting at is… my module needs fine-grained control over which files can be downloaded by which users. So I want the download callback to allow my module to deny access (even if another module thinks it access should be allowed).

Here’s the problem I hope to avoid.

Thanks for the input.

Submitted by Bèr Kessels on Sat, 10/29/2005 - 23:19.

What you say is already somewhat described in the original descritpion.

Since there will be a fileapi() you can develop a module that:
* overrides the upload fields, and prompt the user with your own fields in fileapi($file, ‘form’)
* check if the files are all uploaded as you wish them to be. and if teh correct amount etc is uploaded in the fileapi($file, ‘validate’)
* insert extra data anywhere (in your case about permissions) with fileapi($file, ‘insert’)
* restrict modify or alter your files on view (for inline flash, images etc) and on download (pdfs video etc) with fileapi($file, ‘view’) and fileapi($file, ‘download’).

In light of security and access control

Submitted by dopry@drupal.org on Mon, 11/14/2005 - 05:53.

This provides a lot of power for filemanagement, but It would also be nice to have a way to designate files as public, similar to the current public file system / private file system configuration, but provide both concurrently.

Its one of the biggest problems I have with drupal’s file handling currently. If I want a few private files, every file I upload through the CMS has to de downloaded via apache/drupal and not just apache.

I’ve played with some fixes for it locally, but there is a lot to be done for it to be implemented in drupal core(mainly updates and community support). If this kind of massive file rewrite is going to happen I’d be happy to work on the public/private file handling so they can co-exist.