On Wed, Jun 23, 2010 at 2:58 AM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Tue, Jun 22, 2010 at 2:55 PM, Waldemar Kornewald >> <wkornew...@gmail.com> wrote: >> It also strikes me that a lot of this is being configured at the >> global level -- i.e., you have to nominate that your public upload >> backend will be S3, rather than nominating that a specific file field >> will be backed by S3. > > I'm repeating myself here, but anyway: The primary purpose of this API > is to allow for writing reusable Django apps that automatically work > with your project's file handling solution(s) without hard-coding > anything. This requires that you specify the upload/download backends > separately from FileField (otherwise it's hard-coded and not reusable) > and instead provide a mechanism for detecting which backend should be > chosen for the current request. Of course, this mechanism could take > the FileField into account.
You may feel that you're repeating yourself, but this point certainly wasn't clear to me from your previous two posts. Making it possible to configure the file handling strategy of a reusable app is certainly a reasonable feature request. However: 1) Again, the file storage strategy isn't something that is constant across a deployment. I may want to use S3 for one type of file, but use local storage for another. 2) Handling this flexibility at the level of the request is completely the wrong approach. File storage doesn't change per request -- it's defined per model. Every usage of the Profile model has an 'avatar' ImageField; it doesn't matter how or where you access that field, it needs to be accessed and displayed the same way. This is a per-model setting, not a per-view or per-request setting. There is a larger issue here of how we should treat the problem of configuring the internals of reusable applications. It's analogous to the reasons why we dropped the 'using' argument from Meta declarations on models -- it isn't a decision that a reusable-app-maker can make; it needs to be configured as a deployment decision. The solution for 'using' was to introduce the idea of a database Router; perhaps an analogous approach is required here. > Currently, the django-filetransfers API doesn't get the FileField, but > this could be added. BTW, should the prepare_upload() function > possibly become a member of FileField and should serve_file() and > public_download_url() become members of File (additionally File could > provide a way to get the originating FileField, so delegation backends > can use that information, too)? Maybe public_download_url() could > replace File.url, but that might break the existing behavior where the > storage backend implements File.url, so maybe it's better to just add > a new method to File. Yes - it should be something that is integrated into the FileField at some level. Breaking backwards-compatibility is not an option. >> I suppose my other query would be exactly what you are proposing for >> inclusion into trunk. The API you have documented for >> django-filestransfers strikes me as something that has far too many >> moving parts; there are six different settings, a bunch of different >> utility functions that need to be called at the right times, and a >> couple of views that may need to be deployed. > > There are only three different settings. The other settings were used > to configure the selected backend (this should probably be changed to > be a dict, similar to the DATABASES setting). Every backend is > specified independently (I guess that's what you mean with too many > moving parts) because you really need a lot of flexibility to handle > all the different hosting configurations. The download mechanism is > not necessarily related to the upload mechanism (download can be > X-Sendfile or MEDIA_URL or anything). The public download URL is not > necessarily related to the private serve_file() method (public via S3 > or ..., private via X-Sendfile or App Engine or ...). > >> I appreciate that some of the design decisions you have made in >> django-filetransfers have been made because you're maintaining this as >> an external project. What I want to know is what changes to core you >> are proposing, and how that affects the code that you have already >> published. > > Don't worry about the current code. We haven't yet officially > announced that project and I'll hold it back until it's clear whether > this will be part of Django core or not. We can completely reinvent > the API from scratch if necessary. In which, case, you need to make a specific proposal. I'll admit that this is a problem that needs to be addressed, and I'm interested in seeing approaches that addressing this problem, I can't say it's a particularly high priority for me. I'm happy to give you feedback on a specific proposal, but I have many much higher priority items on my plate for 1.3. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
