Only one backend may be used

[benoitbryon]

Given there are poor chances one wants optimizations for several servers at once (i.e. return Nginx's X-Accel for some views and Lighttp's X-Sendfile for others), one "backend" should be enough. As an example, we should need only one "download middleware" instance, which gets a backend as argument.

As a comparison, django-sendfile uses a unique (and global) backend, then the sendfile() function uses the backend.

=> For most use cases, we shouldn't have to care about the backend when applying optimizations. Except in configuration where we explicitely setup the backend.

Maybe replace "global" by "default" backend, so that override is possible.

[benoitbryon]

This feature may be implemented as follow:

• "global backend" is configured in middlewares, as DOWNLOADVIEW_MIDDLEWARES items. This is not a single backend, but a set of backends. At least they are registered in a single location: settings.
• the recommended practice (in documentation) is to use the global middlewares.
• where you explicitely want a decorator and you do not want to care about the backend, you can use some generic decorator, which accepts most common backend arguments: source URL or path and destination URL.
• where you explicitely want a decorator and you care about the backend, you can use a specific decorator, or a specific list of "middlewares" that can capture the response.

=> DOWNLOADVIEW_MIDDLEWARES makes most use cases easy. => Custom decorators allow fine-tuning for specific needs.

[benoitbryon]

Note about the previous comment... "Download decorators" were introduced mostly to support multiple backend configurations. As of version 1.2, you cannot setup multiple (source, destination) rules for one middleware. So you actually have to setup per-view configuration via decorators. With DOWNLOAD_MIDDLEWARES setting (a list of middlewares with initialization arguments), you can have multiple rules for a given backend. So decorators are no longer the easier way to go.

[benoitbryon]

Created #50 about multiple configuration support. This ticket may not be resolved in version 1.3. After #50 is resolved, a solution could be to create some "generic" middleware that accept a backend as argument (or use global "DOWNLOADVIEW_BACKEND" setting) and use sane defaults for backend-specific options. Then we could have only one middleware class (or backend) and several "rewrite rules" for it. Something like TRANSFER_MAPPINGS in https://github.com/smartfile/django-transfer/

MIDDLEWARE_CLASSES = [
    'django_downloadview.DownloadDispatcherMiddleware',
]
DOWNLOADVIEW_BACKEND = 'django_downloadview.nginx.XAccelRedirectMiddleware'
DOWNLOADVIEW_RULES = [
    (MEDIA_URL, '/optimized-download/'),  # *args
    {'source_url': MEDIA_URL, 'destination_url': '/optimized-download', 'limit_rate': 32},  # kwargs, with specific options
]