TODO

There is currently no locking going during auto-rebuilds, that is multiple
requests could potentially cause multiple builds!

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.

Support functionality for applying a filter directly within a template,
i.e. pack inline scripts. On the other end, allow piping an assets
directly into the template. The latter is probably best using
a MemoryBundle() class that requires an id to be set to replace the
output filename as a cache key.

We should provide functionality to deal with encodings? This seems rarely
needed, since we did fine so far, but still: An encoding property on each
bundle that will be used when opening files (via a respective encoding
property on FileHunk) is simple enough. Then, if you need to deal with a
set of files with a different encoding, you can put them in a bundle of their
own, or define them as a FileHunk() object

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.

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

Support asset deployment to services like Amazon S3.

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.

It might be possible to get rid of the ASSETS_JINJA2_EXTENSIONS setting,
or the requirement that the Jinja2Loader need to know about the extensions
used, if we can somehow hack Jinja2 to ignore unknown tags.

The input filter step can be parallelised. Is this worth it?

Get rid of the global parts. The shipped filters would be loaded globally,
but the filter registry would be maintained by the environment.

See if we can integrate with python-livereload.

A nice feature would be to allow globs overlapping with explicit filenames
while maintaining order. In other words, ['a', '*', 'z'] takes all files but
ensures a is first and z is last.