Hi! I talked with Ber about path mappings and here are my ideas: *) We remove arg() calls from most of core and use parameters to callbacks. *) Instead of linking to node/$nid , we have a give_me_a_path('node', $nid) function. On admin UI you can choose which handler deals with 'node' type paths. This handler gets $type ('node', 'comment' whatever) and $id as a parameter and creates a path. This is the crux of the matter: instead of dumb string aliasing what path module does currently we create an 'intelligent' subsystem. *) I first thought that we need to add regular expressions to menu to match incoming paths against but I am not sure. The current system, I think is able. See below for an example. For example, a mapping for the type 'user' could describe itself as 'puts usernames into the path'. After choosing this handler when url gets ('user', $uid) , it would hand over these as parameters to the username_path function which would grab name field from user table and return with the path "username/$name". This is one SQL query against user table which is approximately the same amount of work that path does currently -- but it queries an indexed table with a numeric index. The function url() would call only one mapping function per invocation as it is now, with the only change that this function comes from a variable. A menu callback would handle the path 'username', with an argument of $name. This callback is as simple as loading $uid and calling user_page with it. So I think this subsystem could scale nicely. Of course, this is a LOT and LOT of work because we need to change EVERY l/url in core to be an 'intelligent' call. But the results! Regards Karoly Negyesi