[TYPO3-dev] set_no_cache is bad. What's next?

[Martin Kutschker]

Ernesto Baschny [cron IT] schrieb:
> Martin Kutschker wrote: on 02.04.2007 15:57:
> 
>>> Basically we need something like cache_hash "enhanced" where we also
>>> count "hits", "last used timestamp", so that we can automatically clean
>>> up old or unused cache entries and just keep the "fresh" and "mostly
>>> used" stuff in cache. This doesn't need to be specific for search
>>> results, but for any information that we might want to cache, but where
>>> we don't want the risk of polluting our tables with infinite number of
>>> entries.
>> Yes, of course. I think this data must be stored:
>>
>> normalized query
>> timestamp (creation time and last time used for shared cache)
>> session id (if a private cache)
>> hit count
>> hits (either as a list, a serialized array or in a separate table)
>>
>> With a normalized query I mean the list of query parameters in a fixed
>> order so the search can be retrieved from cache. May be done with a
>> hash, but still the query should be normalized.
>>
>> If access control comes into play it the search result may either be
>> forced to be private or maybe some session info can be attached to the
>> search result (a list of ids not to be shown).
> 
> Yes, this would be the choice of the extension developer who knows which
> parameters have influenced the search output. I would expect the grlist
> to be attached to the cache entry. In case the extension developer wants
> to attach the session id as parameter to the search result, this
> information might even not be stored in the cache-table (DB) at all, but
> in the current session information. The API might be so intelligent to
> do so in that case.
> 
> If this is the birth of a t3lib_cache, we might check if this can also
> be used by the core itself (BE and FE). Maybe there is code in core
> which we can port to this class at the moment of its birth?

Yep, a standard class should also handle searches in the BE.

Masi