>> Included FileCache implements file-based caching at system/cache. It >> needs to be created an writable, or nothing gets cached.
>> Dashboard gets a cache applied to the incoming links section. See >> that >> section of code to see the cache implemented.
>> FileCache does not yet implement _expire() or _extend().
> I was wondering why we are saving cached items in /system/. Other > than the slightly uneasy feeling having a writeable dir in /system/ > gives me I don't really have any objections, just wondering why we > were using /user/.
I don't particularly like it being in /system either — where are user plugins meant to cache, for example? Making them cache in /system seems illogical. I personally would prefer creating a /cache folder, or, alternatively, creating a /files folder under which every web- server writeable file/folder exists.
> I don't particularly like it being in /system either — where are > user plugins meant to cache, for example? Making them cache in / > system seems illogical. I personally would prefer creating a /cache > folder, or, alternatively, creating a /files folder under which > every web-server writeable file/folder exists.
I think /cache seems the most appropriate. maybe have the following structure?
/cache - content - plugins
and then plugins can cache in /cache/plugins/<plugin_name>/ and the content is cached in /cache/content/. Seems logical to me.
Why would there be conflicts? Why would there be a need to separate system and plugin caches? A cache is expendable, it's doomed from the time it's created and serves a temporary purpose by nature.
Also, the cache location is set via a static that could potentially be changed to use whatever path you want, or I guess a plugin could. Which makes sense as a plugin could potentially add other caching mechanisms beside filesystem.
As it is now, it's dead simple to use, and requires next to nothing from plugin developers. It just works, that is after you create the directory and change permissions on it so that Apache can write to it.
While I might agree that system/cache might not be the best location from a user perspective, since the user would have to create and chmod the directory, I really do not see why we should make it more complex my creating plugin subdirs etc. There is no need for that.
Christian
From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On Behalf Of Robin Adrianse Sent: 21. november 2007 08:42 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: Location of cache folder
I suppose it could be to avoid conflicts, but I think that it isn't necessarily necessary.
On Nov 20, 2007 10:19 PM, Owen Winkler <epit...@gmail.com
I've added a very small patch to issue 487 (http://code.google.com/p/habari/issues/detail?id=487 ) that enables logging if the cache directory is inaccessible. At least that provides a indication to the user that caching is not working and that the cache dir isn't working.
Christian
From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On Behalf Of Robin Adrianse Sent: 21. november 2007 08:42 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: Location of cache folder
I suppose it could be to avoid conflicts, but I think that it isn't necessarily necessary.
On Nov 20, 2007 10:19 PM, Owen Winkler <epit...@gmail.com
> I’ve added a very small patch to issue 487 > (http://code.google.com/p/habari/issues/detail?id=487 ) that enables > logging if the cache directory is inaccessible. At least that provides a > indication to the user that caching is not working and that the cache > dir isn’t working.
> > I've added a very small patch to issue 487
> > (http://code.google.com/p/habari/issues/detail?id=487) that enables
> > logging if the cache directory is inaccessible. At least that provides a
> > indication to the user that caching is not working and that the cache
> > dir isn't working.
