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

[Ernesto Baschny [cron IT]]

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?

Cheers,
Ernesto