[development] Splitting hook_menu into hook_menu and hook_router

[Darrel O'Pry]

On Thu, 2007-01-18 at 21:07 +0100, Dries Buytaert wrote:
> 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.

The old one can be challenging to explain... The confusion seems to
begin around 'type' => ...

> > 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.

The only necessary duplication would be path/array keys. We would have a
smaller memory footprint at ?router_execute? if we're only carrying
callback information and none of the user created menu items. After that
if we only load the visible menu items we have less things in memory.
However we can't say for sure unless there is something to test.

> > 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.

So maybe XML-RPC was a bad example, private files still are. Maybe files
just need there own .php which would also make my point moot.

There maybe some other MENU_CALLBACK(~80)'s that don't need a menu, also
anytime we find ourself at a drupal_goto(~50) we can probably live
without having a menu. So the menu thing is only built on demand we have
a few spots we can avoid building it.