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/