[drupal-devel] upload module
berdrupal at tiscali.be
Tue Sep 20 18:21:37 UTC 2005
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
* 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
* 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 Kessels | Drupal services www.webschuur.com ]
More information about the drupal-devel