On 22 Jul 2006, at 03:18, Khalid B wrote:
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 we have a number of viable ideas here. Let's try to summarize them: 1. Build a caching algorithm that uses an heuristic to pre-load frequently used URL aliases. * Advantages: transparent, no configuration required * Disadvantages: it a heuristic, we don't know how it would perform, it might be tricky to implement, and MySQL does this implicitly (but not as aggressive). 2. Provide a textarea that allows administrators to _white_list_ URL patterns. * Advantages: fine-grained control, easy to implement * Disadvantages: users usually don't like messing with regular expressions, it might take a lot of effort to get the list Just Right, and it takes a certain amount of familiarity with Drupal's URL scheme (learning curve for new Drupal users). The behavior might be confusing: you add an alias, and it doesn't work because you forgot about the list of URL patterns. 3. Provide a textarea that allows administrators to _black_list_ URL patterns. * Advantages: fine-grained control, easy to implement * Disadvantages: users usually don't like messing with regular expressions, it might take a lot of effort to get the list Just Right, and it takes a certain amount of familiarity with Drupal's URL scheme (learning curve for new Drupal users). The behavior might be confusing: you add an alias, and it doesn't work because you forgot about the list of URL patterns. 4. Stop doing SQL queries when you cached all possible URL aliases. * Advantages: transparent, no configuration required, can co- exist with (1), (2), (3) and (5). * Disadvantages: only works for a subset of all Drupal sites, not a solution for larger Drupal sites. 5. Improve Drupal's high-level page caching so we have to rebuild pages less frequently. * Advantages: no configuration required, can co-exist with (1), (2), (3) and (4), eliminates many more SQL queries. * Disadvantages: doesn't work for authenticated users. Thoughts? -- Dries Buytaert :: http://www.buytaert.net/