DownloadView and DownloadResponse use some file wrapper about django-downloadview

[benoitbryon]

basename is an attribute of the download response. Can be different from file's name.

[benoitbryon]

Some examples...

Use case: stream a file which exists on disk.

• django.core.files.File is a suitable wrapper.
• provides "name" attribute
• provides iterator over file contents.

Use case: a file that lives in some model, using a storage.

• model's FieldFile is a suitable wrapper
• optionally provides "url" attribute, depending on storage implementation
• optionally provides "name" attribute, depending on storage implementation
• provides iterator over file contents.

Use case: generate and stream a CSV file without writing it to disk:

• needs a suitable file wrapper
• doesn't provide url or name
• provides iterator over file contents

=> The iterator over file contents seems to be the only mandatory requirement.

=> name and url are optional. Even if they seem recommended for server optimizations (Django could write in a temporary file, but this is not the best optimization).

=> size is recommended, but optional. If "name" is provided, then size can be computed with os.stat. If URL is provided, size could be useful, but in case of server optimizations, the server may be able to add the content-length header. If the file is a virtual one (dynamic streaming), then it seems difficult to provide a size before the whole file contents is iterated. Does the lack of "Content-Length" compromise the download?

=> content_type, mime_type, charset and maybe some other attributes are optional: they can be computed by the response class. However, if they are provided, we should use them, because it allows optimizations and customizations.

=> modification_time seems useful, but could be optional (could default to "always new").

[benoitbryon]

Django's storage API provides "modified_time" (not "modification_time"), "accessed_time" and "created_time".

[benoitbryon]

In Django's storage API (and thus FieldFiles), file wrappers have:

• name: filename which could be relative or absolute. It is a value used to open the file (with open() in case of a local file, with the storage in case of a FieldFile).
• path: absolute local filename. Not provided if storage doesn't support usage of Python builtin open()

=> The difference seems important. Let's keep this design.