On Mon, Mar 28, 2011 at 5:05 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> That's pretty much exactly what django-filetransfers tries to do on >> the download side: >> http://www.allbuttonspressed.com/projects/django-filetransfers >> Hotever it's not only for X-Sendfile, but also for any other file >> serving mechanisms and it's not only for downloads, but also for >> uploads. There's also a corresponding patch (which still needs lots of >> work) for including that functionality in Django >> (http://code.djangoproject.com/ticket/13960). >> >> Is this what you were thinking of? > > Maybe... but there's a *lot* more going on in that patch that I don't > understand. There seems to be no documentation so I'm having to puzzle > through the patch -- all this prepare_upload stuff, backends, > serve_file indirection just confuses me. Not to mention this new "form > traits" mechanism I don't quite get, either. > > I think the big difference between my proposal and this patch is that > my way should be doable without a patch to Django. That is, no new > setting, no internals changes, etc. -- it should all be possible with > a HttpResponse subclass and a set of middleware. I'm not quite sure > what all the additionally complication your patch gains.
I do agree that it's too complicated (esp., the forms) and I plan to improve django-filetransfers in this regard. The biggest complexity comes largely from file upload handling (which I understand isn't a problem you're trying to solve right now). If your main goal is to only handle private file downloads then django-filetransfers already provides a serve_file() view which does exactly that (the only difference is that it doesn't use a middleware-based solution). However, there are other use-cases and hosting setups. For instance, you might want publicly accessible uploads (e.g., an image for an article) to be downloaded directly from an external file server (e.g. S3) instead of going through the Django instance (which would only redirected to S3, anyway). You might even combine two different file hosting solutions (e.g., one for public videos served via a CDN and the other for private gallery uploads). It would be nice to have an abstract API that can handle all this, so (even for internal apps) one doesn't have to maintain several forks with custom file upload/download handling code. The patch attempts to solve this and django-filetransfers does the same as a separate app (with the disadvantage that the admin doesn't use it). Both solutions have lots of room for improvement, though. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
