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.