In an earlier post I discussed the fileinfo problem, where one of the drawbacks of using the system I'd devised was a major burden on the designer when adding a new template or changing a template mapping. I'm now in the middle of seeing if these things can be ameliorated with an approach being explored in a new code branch.
The idea is simple: Fileinfos are built as late as possible and on demand. This means the slowest operations are:
Most of these, I think, are going to be one-time slowdowns. The second one is likely to be more burdensome, and only for designers -- and even there I plan to ameliorate it by way of queuing things so they can be accomplished as passively as possible. The biggest drawback there is, while the queuing operation is in progress, you can't edit or change any templates -- but that's something that's consistent throughout the program anyway.
The biggest inconvenience for lay users will be #3, but again, that's something that doesn't happen often and can be partly ameliorated by way of queuing.
I think in the long run this may prove to be the more flexible approach, simply because you can always force-build fileinfos on your own schedule if needed, and just get it out of the way. The command-line client I have in mind for this sort of thing will offer such a function.
One last thing I'm thinking about is to allow, on systems that permit it, the build queue to be run entirely in the background in a noninteractive way, and to only alert the user if something goes wrong -- e.g., send an email, or maybe do some kind of long-poll push notification.
The way the queue works right now is by way of an AJAX callback -- you have to keep a window open, but it doesn't have to be the editor window. Or if is the editor window, you can go about your business editing stuff. I'll be experimenting with a few alternate approaches once things are further nailed down.