NYCPHP Meetup

[Patrick May]

On Mon, Jul 21, 2008 at 4:26 PM, bzcoder <bzcoder at bzcode.com> wrote:

> I don't consider an extra millisecond or ( even 5) when editing a web page
> to be poorly performing, as the human based edit process is already
> structured around making changes, hitting save, waiting a second, making
> more changes, etc.


Oh I wasn't thinking of an extra millisecond to be too much for the editor.
I referring to the 5 minutes of waiting for caches to clear b/c the cache
isn't integrated with the event of CMS updates.  I'm sacrificing the
occasional 500ms wait for content in favor of simplified code management and
integration, with the goal of more widely deploying perfect caching.

If the content generation stretches above 500ms I agree pre-generation in
the CMS is necessary.  I wonder if there's a pattern here that could also be
supported by the library?

Also, you are correct that you can embed information in the cache files.
What I'm going for is some library support to automatically clear both of
these caches on article updates:

  /cache/article/1234
  /cache/frontpage/article/sidebar

I know this could be done with:

  system('find /cache | grep article | xargs rm -f');

and I do question what's wrong with such a simple line of code :D

I want a simple abstract "clear cache" line of code to embed in various CMS
locations, while the actual mechanics of clearing cache are managed by the
library.  By simplifing the process of describing something that is cached,
I hope to have widespread 'perfect' caching.

I've got the code written for another project, just need to fiddle with the
namespaces and release it.  Thanks for the help thinking through the idea.

Cheers,

Patrick


-- 
Patrick May
135 Oak Street
Brooklyn, NY 11222
+1 (347) 232-5208
patrick at hexane.org
http://www.hexane.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20080721/5b96fa2e/attachment.html>