I am not on favor of tying this to any one system, e.g. making this only available if you muck around with the HiEngine. I think the engine us ctuslly quite nicebut I don't intend to ever use it.
I shouldn't be forced to learn a new language syntax to use this functionality. It should be agnostic to the theme engine that is calling it. Sent from my iPhone On Apr 27, 2009, at 9:11 PM, Owen Winkler <[email protected]> wrote: > > Arthus Erea wrote: >> >> Furthermore, there should be an option to disable the cache somewhere >> in the UI. That would give tinkerers the ability to work on the >> theme, >> then re-enable the cache when they're done. >> Where should such an option be? In the theme config or in the main >> settings page? (I'm leaning towards main settings.) > > Sounds fine to me. > >>> There really isn't a need to use that one directory, but it would >>> make >>> it easier to route requests. I imagine a rewrite rule that resolves >>> to >>> a single hook, where the file that the request asks for is passed >>> in. >>> Plugins/Themes that can resolve the file simply return it, and the >>> system takes care of putting the file where it belongs and managing >>> versioning. The plugin would call a specific function to clear a >>> file >>> from the build cache. Also, some logic for versioning and >>> appending a >>> querystring to the URL (like .../style.css?6) would be handled by >>> the >>> system. >> >> What would the benefit of the querystring be? Shouldn't there really >> just be one version regardless? > > If the CSS is served properly, it will come with headers that set a > long > client-side cache life. This is a benefit because it will avoid the > client from continuously requesting updates of the CSS from the > server. > The downside is that if the CSS is actually updated on the server, > there's no way the client would know, since its cache settings tell it > not to request updates. > > The remedy is to add a simple querystring with a version number. The > querystring is ignored by Apache, but the browser sees it as a new > URL, > which circumvents its previous cache settings for that file. The same > file is served, but by adding the querystring, the client behaves as > though the cache must be refreshed. > > Upon receiving the new file, it is once again cached, hopefully using > the same settings as before, and will subsequently not be requested > again until that querystring number is updated. > > This is a fairly standard method for implementing a solid client-side > caching strategy, while still enabling server-side changes to > propagate > to the client. > >> In terms of HiEngine, I wonder if we could actually run both PHP and >> HiEngine at once on the generation. I'd see it working like this: >> 1) We open a buffer to catch the output >> 2) The stylesheet is included >> 3) We run the resultant css through the HiEngine >> 4) We output/cache the CSS >> >> Since most requests will be served from the cache, this shouldn't be >> too much of a hassle. > > I'm not sure what this is meant to accomplish, but it seems > unnecessary. > > Owen > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
