New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DownloadView and DownloadResponse use some file wrapper #23
Comments
basename is an attribute of the download response. Can be different from file's name. |
Some examples... Use case: stream a file which exists on disk.
Use case: a file that lives in some model, using a storage.
Use case: generate and stream a CSV file without writing it to disk:
=> 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"). |
Django's storage API provides "modified_time" (not "modification_time"), "accessed_time" and "created_time". |
In Django's storage API (and thus FieldFiles), file wrappers have:
=> The difference seems important. Let's keep this design. |
…rapper to download response. The file wrapper encapsulates file attributes such as name, size or URL (introduced URL).
…DownloadView is to replace an use case of former DownloadView.
…torageDownloadView is to replace an use case of former DownloadView.
…r basic support of in-memory (StringIO) or other generated files.
In download views, we want to instanciate a download response.
We currently compute file attributes (size, name, ...) and pass it to the response constructor.
The more attributes (see #21), the more the response class gets complicated.
Moreover we would like these attributes (see #22) to be lazy.
We could implement some methods that support storages (and thus, FileField and ImageField).
But then, what if someone wants to change the behaviour? He would have to override the response class.
The response class should have some "file" (or whatever the name) attribute, and handle it via some API. Could sound like "the response's file attribute is an object with url, filename, basename, size... attributes".
Then it would make it possible to have various implementations for this "file wrapper". One would use Django storages.
Could look like django.db.models.fields.files.FieldFile, but not tied to models.
Could help #5, #21 and #22.
List of attributes for the file wrapper:
Are these attributes needed?
The text was updated successfully, but these errors were encountered: