TODO

Should bundle names be namespacable, similar to Django urls? At the least,
we probably want to encourage a convention of prefixing your bundle names
with an id. Everything else would just intend to make this easier or more
transparent; for example, bundles could be automatically namespaced based
on which app's assets.py file they are defined in, and the template tag
could look at request.current_app when resolving, or take an argument.
There should be some solution though, since it's easy to clash with names
like "js" or "js-all". "admin:js" works much nicer.

--parse-templates currently breaks on asset tags that refer to bundles
by name.

Allow callables that act as filters to be source filters.

Since running an external tool is not uncommon for a filter, the Filter
base class could support a helper function that simplifies the calls to
the subprocess module.

Our updates currently only consider the timestamps, not the assets settings;
that is, adding a new filter or file to a bundle will not cause it to be
recreated automatically.

Automatically create (and delete, i.e. manage) symlinks to make the
ASSETS_EXPIRE="filename" option work without server rewrites.

(a) Support functionality for applying a filter directly within a template,
i.e. pack inline scripts. (b) On the other end, allow piping an assets
directly into the template.

(c) Support a "apply filter but do not merge" mode in which every source
file is written to a corresponding file in a given output directory;
without having to explicitly create a separate bundle for each file. How
would this behave in a nested scenario?

With respect to (b) and (b), it will be challenging to support all those
combinations from within the Django template tag, with it's limited syntax.
Note that the two features do overlap: Both deal with how to output an
asset.

Should be provide features for normalizing encodings? This could be
added as properties to the bundles.

Handle far future expires for images: add a new templatetag that can output
image urls with timestamps; the cssrewrite filter could modify urls within
CSS files when ASSETS_EXPIRE is enabled.

Support image sprites like django-media-bundler does.

Find a good solution to making filter debug/log information available in a
standardized way across the board.

Allow an option to fall back to rendering source files in case asset
building fails for some reason. Right now, the user would get to see a
server error. This would probably most simply be accomplished by having
AssetsNode catch exceptions in create_merged() and redirect to
render_sources. We probably want to activate this only in production mode.

Support asset deployment to services like Amazon S3.

In the beginning, there was this idea of "tracking" assets in a model, to
avoid having to parse templates. Now that we conceptually moved towards
defining Bundles in code, that's no longer necessary. Still, there could
still be some uses for it; note enough probably to justify the feature, but
let's note them anyway:
	- The model could store things like the bundle hash, allowing a
	  hash-based update mechanism, even when using say a timestamp cache
	  buster, or no cache buster at all.
    - Right now, if asset properties like the applied filters or the list
      of source files change, without causing the source timestamp to
      change, the update will not be automatically picked up. That kind of
      information could be tracked and used to detect changes better.

Support more expiration/cache busting options (e.g. append hash, use hash
instead of filename, ...); Allow custom code as well.

Add support for Bundle subclasses to customize behavior on a
bundle-by-bundle basis:
	- The merging of filtersets.
    - Determining when an update is necessary.
    - How to expire assets
Basically, all the settings should be customizable this way, with the
settings themselves only serving as a default.

Currently, the docs claim that in a case like this:
	Bundle(filter='cssutils', ...),       # (1)
	Bundle(filter='less,cssutils', ...),  # (2)
	Bundle(filter='cssutils', ...),       # (3)
django-assets cannot apply those filters in two steps. Truth is, we're
just not smart enough; ``less`` COULD be applied first, and then cssutils
over the rest.

How do we currently handle something like this?
    less = Bundle('css/base.less', 'css/forms.less', filters='less',
                  output='gen/less.css',
                  debug=False)
    register('all-css', less, 'css/jquery.calendar.css',
             filters='yui_css', output="gen/all.css",
             debug="merge")   # <- !!!!
It seems like this should be a single file, but it probably isn't.

Provide a JSBundle, CSSBundle, AutoDetectBundle (for use in templates)
base classes which would provide a default set of filters; the idea is
to make starting with django-assets easier, but I'm not entirely
convinced it makes sense.

The whole compilation process could be sped up significantly if each
individual step (i.e. every time a filter or a set of filters is applied
to a file) would be cached somewhere (say a temp directory). Rather than
recompiling a bundle in total on every change, only those s subtrees
actually affected would need to be processed.
This might also provide us with a simple way to detect changes based on
which filters are applied, or which source files are contained in a
bundle; changing those properties currently may not cause django-assets
to detect a bundle has having changed, since it only looks at file
timestamps. The cache could easily employ filenames entailing this
information. However, note that this might not be good enough; is the
cache always available? Or would one turn it off in  production mode?

Some thoughts on how to use django-assets with compass
(http://wiki.github.com/chriseppstein/compass), and how to integrate the
two (if that makes sense at all). Generally speaking, compass provides
a command line util that is used a) as a management script (like
django-admin.py) doing for example setup work, adding plugins to a project
etc), and b) can compile the sass source files into CSS, and even compress
them. it's this latter functionality that provides some of the functionality
django-assets would be used for, but not all. compass alone doesn't provide
for cache busting, nor can it merge the multiple CSS files it processes
into a single output file. It therefore seems like there is room for
integration.
	*) The sass filter could be used to compile the source files, the
	   compass command line utility would only be needed by the dev to
	   get started with a new project, or adding plugins. The compass
	   compiler is not used. Not sure if there are compass specific
	   extensions yet that a pure sass can't compile.
	*) A compass filter could run the compass command line utility, based
	   on a given project file; and then expand itself into the individual
	   source files given, which could then be further processed by other
	   filters. Support for this "expanding of files" by filters needs to
	   be implemented first.
	*) Simply a way to cause the compass compiler to be invoked whenever
	   the django-assets compiler runs, so that not two steps are required
	   to update ones assets.

Right now, our filters can either be a source or a target filter; it's
probably better design if a single filter could act as BOTH source and
target filter at the same time.

Some filters, like the less filter, cannot work with an input stream,
but only with the source files directly. To work, they thus need to be
the first ones to be applied. There should be a way for filters to declare
that requirement and django-assets to automatically validate it.

The less filter has one problem: It is *slow*. I'm not sure whether this
is the default of Ruby or Less itself, but starting up the compiler for
each source file gets unacceptable very soon during development. It's
quite possible that other filters that startup processes, like YUI, have
the same general problem, but it's not noticeable as easily due to that
filter only being applied one for each bundle, not for each source file.
Here are some ideas to improve the situation:
	- Currently, we support a "less daemon" mode through a fork of less.
	  The less daemon runs in the background, and we ask it to compile
	  stuff through a TCP connection. This helps a lot, but we cannot
	  realistically expect to add support for such a daemon mode to every
	  slow filter.
	- Somewhat hacky, but a special type of bundle could change the extension
	  of it's files while in debug mode, between .less and .css. Then, the
	  less compiler could be run in watch mode by the developer, generating
	  the .css files for each .less file, and the bundle would cause the
	  .css files to be rendered as long as we are in debug mode. While
	  in production, the bundle would expose .sass files, and the normal
	  filter/merging process of django-assets is done. This at least helps
	  during developing.
	- Before we do that, however, it would probably be much smarter to
	  simply add a daemon mode to django-assets. It would recompile bundles
	  in the background transparently, as soon as the developer makes his
	  change. This would therefore work for all types of filters.
	- The less files could be pre-processed to rewrite relative urls
	  to included files. This being the main reason why we need to run
	  less for each source file, it could maybe rid us of this requirement.
	- The per-file caching suggested further above would help a lot; no
	  longer would it be required to recompile all source files on every
	  change - only those that actually changed.
A combination of various of these approaches may be used.