Page History

The current state of affairs when it comes to cache lookup URLs is quite a mess. This document describes the outline of the changes I'd like to make. Part of this includes eliminating a few APIs, which depend on a strange concept of a 2nd cache state machine. The proposal includes the alternatives I have for this, but bear in mind that the implementation of those alternatives belongs in different project plans.

Problems

There are a number of issues with how we deal with cache URLs in the code right now:

• There are a number of URL objects that are setup to store potential cache keys. It's quite a mess, and some of them are already dead code. Some of them come from the 2nd cache state machine (more details later). This makes the code overly complicated, and suboptimal.
• The current API (TSCacheUrlSet()) to modify the cache key is inflexible and slow. The reason for this is two fold:
  1. The API takes a string, which has to be parsed as a URL creating a new URL object internally. This is not only slow, but means the cache key has to be a parseable URL.
  2. To create the cache key (an INK_MD5), we have to stringify this URL object again (undoing the parsing), and do an MD5 over this string. These are simply wasted cycles.
• There is no easy way to make a small modification to the cache key. You have to create an entirely new URL cache key.