Hello I decided to fork upload module, in an attempt to make it better usable, and change some other thingies. It is called betterupload, yet he filename remains upload.module My first landmark was to split it into upload.module and upload_display.module. The goal of this, is to make upload into an API-only module (i.e. a module that does nothing special really) for uploading files with nodes. No tables, file lists, inline images ad what more. Just uploads. With hooks and APIS, off course. upload_display takes care of displaying that table we have now. podcast.module could take care of nice podcasts. Inline_uploads.module can handle inline views, whatever_upload module can do the whatevers. My aim is to maintain this alongside (as much as possible) the core upload module. But to allow much faster and much more dynamic development. I feel core demands stability and security above all. But this very much limits the speed at which stuff can be developed for core. Basically anyone can contribute, as long as it remains within (usability) limits. So adding lets say, very pdf specific stuff in uploads, is not really an option. And of course this is a testcase to see if modules without those everlasting core discussions and -polictics ca deverlop themselves into better alternatives then core modules. I beleive this might very wel prove a nice workflow: let a feature prove itself core worthy by having it as contrib. Once its tweaked, revised, rewritten, again, and used by a lot of users, it can get into core. This tackles a few problems that I see in the current workflow: * Too much talk too much politics a lot of code, yet very little solid improvements. Our current system very much encourages tweaks, above solid rewrites. * Users (as in those USING) have no way to get involved in the development process. With this forking thing, they can influence, by merely using. Instead of only being able to rant about all hose new thingies in 4.7, once it is released. * Developers have a far quicker and looser way to get their code in. Uer feedback, developers feedback can then, later iron out the issues. (reverse reviews) * If such a project, finally makes it back into core, we can be sure it has passed the users test. Instead of merely passed four of five reviewers, it will pass both tests. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]