This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further. * Modules get their own directory. (modules/system/system.module). * All modules get own .install (modules/comments/comment.install). This way, all the relevant tables of a module are "closest" to the source, and won't actually get thrown into the db until someone enables them (I hate the fact that I've got about 15 tables I'm not using in my Drupal database. Just drives me nuts.) This also helps update.php in that it will only need to go through ENABLED modules, instead of performing updates for unused tables. We can also pre-create/publish nid 1 in modules/node/node.install without having that dummy hardcoded text, a long standing issue. * databases/ directory is removed entirely. By giving each module their own .install, we don't really need databases/ anymore - we'd just need to, at first run, check if table system exists. If not, find all required modules and run their .install. This way, we remove the entire schema creation step of the INSTALL. All the existing updates.inc would move into system.install. This is nice, IMO, because it'll make a purdy friendly installer a lot easier to create (as it'd just have to send to the frontpage after DB config/QA instead of sucking in databases.mysql). * Modules get an activate, deactivate, and uninstall hook. I think Merlin was working on this to some degree. Activate enables the module, deactivate disables it, but keeps the created data, prefs, and tables in place, and uninstall removes everything. This mimicks the operation of Gallery 2 modules - the uninstall part is awesome! If I use search.module for a week on my 5000+ node site, then find out it's just not good enough, I don't want those gigantic tables hanging around forever, taking up backup space. If I uninstall search.module, those tables and data should be removed. * .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?) * By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files. I coulda swore I had more in the shower, but I've to go to work now. -- Morbus Iff ( accept no prostitutes ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus