[drupal-devel] upload module

[Bèr Kessels]

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 ]