I should probably just store the information via sfCache and allow sfAPCCache etc. to be plugged in as an alternative to the default sfFileCache to avoid overhead rather than being cute about it...
On Aug 17, 9:39 am, Stéphane <stephane.er...@gmail.com> wrote: > I didn't took a look at the implementation yet. > > PHP is caching filesystem infos AFAIK. > > Can't we use these file informations as part of the key cache to compute md5 > ? So their will be no more need to invalidate, it will invalidate by itself, > or by calling (for hard-writting apps) clearstatcache() ? > > Cheers, > > Before Printing, Think about Your Environmental Responsibility! > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! > > On Tue, Aug 17, 2010 at 3:32 PM, Tom Boutell <t...@punkave.com> wrote: > > Daniel, this almost works and I got pretty excited thinking about > > it... but there's a tragic flaw. > > > On the first page access you slurp up all the CSS files, minify them, > > md5 that and create a cache file. Fine. > > > On the second page access you... can't point to the cache file without > > first doing all of that again (everything except actually writing the > > file) just to figure out what the filename is. (: > > > Opening all of the files, slurping them in and md5'ing them on every > > page access is overhead we do not want. So it makes more sense to have > > a cache key. > > > On Aug 16, 9:13 am, Daniel Lohse <annismcken...@googlemail.com> wrote: > > > Sorry for being a bit slow today: why would we need cache invalidation? > > If the filename of the compacted file(s) is a hash generated from the > > contents of the file then after one file changes and the scripts/stylesheets > > are re-generated the filename changes. The browser then should just request > > the file because it doesn't about that file yet (filename is not the same). > > > > Am I missing something here? > > > > Cheers, Daniel > > > > Sent from my iPad > > > > On Aug 16, 2010, at 2:59 PM, Tom Boutell <t...@punkave.com> wrote: > > > > > You're right, we do need cache invalidation. I just came up with a > > > > clean way to do it without tweaking app.yml settings, adding a table > > > > or making glob() calls: just use a file in the asset-cache folder to > > > > hold the current cache key. The OS should cache reads from that file > > > > extremely well. > > > > > It may even be possible to avoid the filesystem hit by writing it as a > > > > PHP file in cache/frontend/prod/config that just calls > > > > sfConfig::set(). Then with any luck it would be autoloaded and even > > > > cached by APC until its modification date changes just like an app.yml > > > > setting would. But plain old file_get_contents() calls to a simple > > > > file with an asset cache version number in it would also get cached > > > > nicely by the operating system so it might be overkill to try to wedge > > > > it into Symfony's cache. > > > > > On Aug 15, 11:44 am, pghoratiu <pghora...@gmail.com> wrote: > > > >>> It might be worthwhile to take things a step further by versioning > > > >>> them in the URL so that they can be given an infinite cache > > expiration > > > >>> date, although this requires a database hit or perhaps a glob call > > > >>> when outputting the pages that contain them. The code is a big step > > > >>> forward as-is if you are using unminimized, uncombined CSS and JS and > > > >>> has no negative impact on your existing caching issues, but we'll > > > >>> think about next steps. > > > > >> ==== > > > >> I think think it's important to add cache invalidation as well. My > > > >> suggestion is to append another key > > > >> to app.yml to have a cache key that can be updated manually and append > > > >> that key too the minified resource > > > >> file: > > > >> all: > > > >> a: > > > >> ver:1 > > > >> css/main.css?ver=1 > > > >> This way css and js pages can be cached indefinitely on the client > > > >> side without having problems when manually > > > >> updating the css or js files. > > > > >> gabriel > > > > > -- > > > > If you want to report a vulnerability issue on symfony, please send it > > to security at symfony-project.com > > > > > You received this message because you are subscribed to the Google > > > > Groups "symfony users" group. > > > > To post to this group, send email to symfony-users@googlegroups.com > > > > To unsubscribe from this group, send email to > > > > symfony-users+unsubscr...@googlegroups.com<symfony-users%2bunsubscr...@googlegroups.com> > > > > For more options, visit this group at > > > >http://groups.google.com/group/symfony-users?hl=en > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > You received this message because you are subscribed to the Google > > Groups "symfony users" group. > > To post to this group, send email to symfony-users@googlegroups.com > > To unsubscribe from this group, send email to > > symfony-users+unsubscr...@googlegroups.com<symfony-users%2bunsubscr...@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/symfony-users?hl=en > > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
