On 1/23/07, <b class="gmail_sendername">Khalid B</b> <<a href="mailto:kb@2bits.com">kb@2bits.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+1 from me too.<br><br>I think the potential for speed is huge for this patch. The less files we load the <br>faster Drupal will be for sure.<br><br>Some comments:<br><br>- I am torn about the .register file though. Why? Because we are moving towards too
<br>many files already (first .install, then .info, then .register, then .foo, ad nauseum). <br>Perhaps this is overcome by one hook only modulename_register() or <br>modulename_callbacks().<br><br>- Another option is to have a compiler for Drupal. Once a site is "compiled"
<br>all the modulename_callbacks() functions are written to ONE file for all the<br>site's modules and themes, or perhaps two files, one for core and the other <br>for contrib. This single file (or two), can be loaded once instead of some
<br>30 .callback or .module files, which will be faster. We then get the benefits <br>of Karoly's split patch as a bonus.<br><br>- In development mode, the compile step is dynamic, making the site slower,<br>but guaranteed to be "fresh".
<br><br>- We can even make the development mode be the default if we want, and<br>the compile step is an optimization step for sites who need it.<br>
</blockquote></div><br><br>More thinking aloud:<br><br>The compile step can be done on-demand as well, but requires the web server<br>to have write access to the master .callback. It can detect if the time of the<br>files have changed and then generate the master .callback file. Much like we
<br>do the menu cache in the database today.<br><br>Heck, we can store the callbacks in the database as well. Not sure if that is<br>faster or not. We already store the modules and themes in the system table.<br>