[development] Splitting hook_menu into hook_menu and hook_router

[Dries Buytaert]

On 18 Jan 2007, at 20:30, Darrel O'Pry wrote:
> 1) Lower Barrier to Entry for Developers, Self Documenting Hooks.
>
> Hook_menu currently does two things. URL to callback dispatching and
> defining module provided menu items. It's a little counter  
> intuitive. I
> thin splitting the functionality would make it easier to understand  
> how
> Drupal handles initial page loading, without having to get into the
> details of building a visible menu. Two simple self explanatory API's
> are better than one confusing API.

How many minutes does it take to explain the old/current menu system  
to someone?  How many minutes does it take to explain the new/ 
proposed menu system to someone?  That's the ultimate test.  I think  
that the new one is easier to explain, but I haven't actually tried.

> 2) Improved memory usage.
>
> People might not care about memory and performance on the surface, but
> ISPs care about server resource usage, site maintainers worry about  
> the
> number of visitors their site can support and their hardware needs in
> relation to supporting their community, and site visitor care about  
> how
> quickly the page loads.

Why would splitting the router and the menu reduce memory usage?   
Have you tested this?  I'd think you end up with more arrays and some  
duplication.

> 3) Lighter Bootstrap.
>
> For cases like private files and xml-rpc interactions where the  
> visible
> menu is not needed, there is less data to crunch before we get to the
> workhorse callback.

The XML-RPC backend doesn't actually use the menu system so your  
example is moot.  It has his own dispatch mechanism.  Even if it  
would use the menu system, 99% of the time people are serving pages  
with menus.  We should optimize for the common case.

--
Dries Buytaert  ::  http://www.buytaert.net/