Problems with the current "asset dependencies" approach

[mpdude]

As of #362 we've got the possibility for filters to implement a particular interface for deep dependency extraction. If they do, they are presented the Assets' contents (in the state before they are applied) and can then return new Assets to indicate additional files that are relevant when it comes to re-generating/re-processing stuff.

Currently, these new Assets are just used to calculate a single "all dependencies included" last-modified-timestamp.

Problems with that:

• If more than one filter is applied and dependency-aware, all previous filters need to be run repeatedly to have the right input for filters at the end of the chain
• The "deep mtime" cannot reasonably be used for cache validation as it might be expensive to calculate (scanning Assets for "deep deps" is one thing; but it might also lead to executing filters)

I think we should focus on the second one. If we fix that, the first one is just some penalty incurred when we initially generate stuff and cache it.

One solution might be something similar to Symfony's ConfigCache - we need to "deep extract" the depended-on Assets (or files, or globs, or whatever). The next time we come back to validate a set of processed assets, we look at that list and mtimes and not use the extraction process again.

@kriswallsmith Please correct me if I am getting facts wrong.

[kriswallsmith]

I agree there is plenty of room for caching here.

[mpdude]

So before we start tweaking the deep mtime too much here, maybe we should try to get it as good as possible in AsseticBundle and have only the minimum support necessary in Assetic itself?

That way we might be able to leverage the ConfigCache.

[demonkoryu]

@mpdude Think of us poor ZF2 users.

[kriswallsmith]

@demonkoryu don't worry, this work will be done here

[mpdude]

If we had a helper class that collects the "deep" assets, maybe one could serialize and keep that for later requests. It would then be used to re-iterate those assets, check their last modified again and return whether or not one changed. If so, re-generate stuff as usual.

That way, users only need to somehow keep one object and query it before they do the expensive stuff.

Thoughts? I don't want to slip into re-inventing sf2's ConfigCache here.