TODO

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

Add a switch to the rebuild() command to ignore the cache.

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.

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.

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

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.

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.

Support asset deployment to services like Amazon S3.

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.

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 webassets to automatically validate it.
One possible option: Adding a new method besides input/output - say, "open()".
Only one such filter would be allowed to run.

I was never really happy with the debug=False approach to solving
the CSS compiler in debug mode problem. Maybe it should be up to
filters to decide if they need to run. There shouldn't really be
a case in which, say, "less" should NOT compile. The output wouldn't
be usable in the browser otherwise.

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?

Creating a custom CLI is too complex currently. It should be possible
to use an existing class which does all the parsing, only providing
an environment instance.