[development] Caching, caching, caching...

[Khalid B]

On 7/21/06, Gerhard Killesreiter <gerhard at killesreiter.de> wrote:
> Khalid B wrote:
> > What Ken Rickard said makes me think of another solution:
> >
> > If we provide a generic way to exclude certain paths, that can cut down
> > the processed aliases.
> >
> > For example, a site may only want to alias "taxonomy/term/*" and
> > "node/*" and nothing else.
> >
> > Another site may only want aliases for "node/*" and "user/*"
> >
> > The code this way is generic and customizable on a per site
> > basis with no patches, ...etc.
> >
> > You get the idea ...
> >
>
> Interesting idea. We could look at the system urls that actually are
> aliased on a particular site, try to abstract some regexp from them
> (mainly by replacing numbers by a regexp matching numbers, I'd think.
> Maybe also by truncating them.) and store the resulting regexps in a
> variable. Then, before we'd look for a matching alias for a particular
> system url we can first match that urls against our regexps.
>
> I somehow doubt that this would be faster, though.

Actually what I meant was sort of a filter for the admin (or  modules)
on what should get aliased and what should be ignored.

This way, we cut down on the number of useless aliases (for that
particular site). If a site restricts aliasing to $_GET['q'] of
^taxonomy/term/\d$
^taxonomy/term\d/feed$
^node/\d$
^node/\d/feed$
Then menus become a non issue. They do not take up space  in
the database, they are not queried either.

The above pattern is enough for the majority of sites (perhaps with
user/* as well). Modules like pathauto can use that to
 add or remove patterns too.

So, the speed in limiting what gets aliased, and what doesn't and
what gets queried and what doesn't.