First of all: Moderators, if you think this is not the right place for this topic, please move it. Just no to the "recicly bin".

Second of all, I am a beginner in drupal development. It may happen, that a lot of things I state below, are not ENTIRELY true, these are my impressions and ideas.

Third: Beware, this is a long post...

I am frustrated. I have an idea to implement, but i kind of hit obstacles with every single module I try to tailor to my needs.

The problem with easy image handling and upload is so old, that it starts having a beard. A lot of people and developers tried to address this point with different solutions - and please allow me this comment -, but seemingly without conception. At this point I have 68 modules (counting only directories) installed and there are too many of them offering the same in different flavour. And what is good in one of them, is missing from the second.

For example, there is image modul, image_attach, and image_assist. It works fine for a plain-text solution, but what If I would like to combine it with TinyMCE? I can't. The module that works with TinyMCE is IMCE, but that does not upload images as nodes, so I am missing the gallery functionality, the ability to browse all the uploaded pictures in a "themed" way. Running two different solutions for handling images seems to be unprofessional. Code reuse? Forget it. Yet there is CCK's imagefield and imagecache. A third solution...

Then there is the audio module. And the audio field in CCK. And the support in views module for audio... Analogically, there is the video module with a really extensive list of modules and functionality, PLUS there is the flashvideo module, PLUS there is the videofield in CCK in the "mediafield" bundle. Did I forget AcidFree?

It's clear that every tool isn't a hammer and every problem isn't a nail, but I would like to see a unified solution for all these problems.
My understanding - from a user's point of view - is, that all a user wants is to edit text, and add media... and do this using the way with the least resistance. Mostly they don't want to create specific content types, like audio node, or video node, or post... they want to create RICH CONTECT. On the contrary, as a developer or site admin, we would like to limit the users and prevent them from breaking our layouts, using unesthetic colors and styles, we want to make sure that they attach a picture if we try to run a gallery site, etc., etc., etc. Yet I believe both goals can be achieved with an appropriate design.

SOA is very popular these days and I think it should have its provisions also in Drupal.
I imagine a solution, where a module would offer nothing else, just generic UPLOAD capabilities. A second one would just handle storage, quotas per users/file types, etc. Then a third, that would do file-type specific handling, create nodes for the files and probably use the services of a fourth module, that would offer [for example] temporary or permanent image resizing or ID3 tag retrieval. Then there would be a fourth, that would offer rendering capabilities (content display) of a specific node-type. I expect such rendering capabilities would need to offer full node display and inline [filter] display modes.

Once this would be working, we could write arbitrary plugins to -for example- TinyMCE, that would insert the filter tags into the text, or define placeholders for the rich media or other data beforehand, and thus create COMPOSITE structured content types. In my understanding the latter is CCK just with a different approach.

So all in all, CCK is a move into the right direction when considering structured content, but I still miss the code reuse in its modules and the service oriented approach. Especially, I would welcome if the media specific fields could be used also in unstructured content types in the form of filters, and offering the same benefit and user comfort with the handling (upload, resize, edit, etc.).

I don't think implementing this would be too time consuming or require more time than ppl are willing to sacrifice for Drupal. A lot of effort has already been spent on the developoment of duplicate functionalities which is wasted time. Having used that time for good analysis and architecture we would already have a consistent approach and more rapid development. Keeping in mind that different modules are developed by different ppl, a good specification and framework is vital to keep the architecture in consistent.

As I said in the beginning, I am a beginner with drupal development, but I am fairly experienced with software architecture and most importantly I am willing to participate in the design and partially in the implementation of such an approach.

Two questions to finish my post:
1. Are there people willing to pursue and actually DO something for such an approach inside Drupal?
2. Do you see any chance that this could be implemented already for the 5.x branch, or are there substantial obstacles to this?

Comments

sepeck’s picture

1. people are already working on this. see various development list traffic in the archives. It's not simple and quite possibly will need a few versions of Drupal to fully implement as do many things that have been implmented.
2. Drupal 5 core is frozen. No new features or api changes will occur within that branch.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

chx’s picture

Isn't this what dopry is working on? fileapi, filesystem and so on?
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | Local dip sour | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

dopry’s picture

I've been working in this direction for a while. I feel your pain, but I've been slow to address them. Most of what needs to be done can be done with relatively minor changes in file.inc and upload.module. My current roadmap for 6 is along the lines of:

-files owned by uids so we don't have to store files in 'temporary' states while waiting on an nid.

-resolving the filepath relative to drupal's root instead of file_directory_path().
since we store file paths as 'sites/default/files/[path]' we can't go around switching public/private files or changing the file path in drupal without breaking all of the file handling.

-public and private flags per file.

-hook_file() for all the file_ functions so modules can react to them.

then some deeper FormAPI goodness like a fileupload element that does the work of getting it in the db for you.

all of which I have implemented working versions of in fileapi or filesystem at one point or another then quickly broke as I extended the scope of the modules.

I'm not sure what you mean by SOA, but if you can detail some concrete ideas you have for making things work better it would be appreciated. If you mean start of authority. In Drupal modules don't really get authority over much. They have to work cooperatively to a certain extent.

notabenem’s picture

Good to know that I am not the first with this idea.
So file functions is already being worked on, and I've seen an API effort in the Audio and Video module. These are however isolated attempts where we risk that the modules won't fit into each other nicely. I would recommend starting a discussion board where all the already implemented and newly designed functionalities would be visible for the participating modules. This would help foster cooperation and prevent duplicates... + a kind of steering is something that would definitely have positive impact on this.
-M.

dopry’s picture

there is a place on groups.drupal.org for this... http://groups.drupal.org/file-api Its not very active, but people have used it to share ideas.

There is cooperative work going on. It's just happening in IRC, in person, and on groups.

notabenem’s picture

I have just discovered this project proposal in Google SoC:
http://drupal.org/node/120677

I hope this will be implemented, since this fits completely into the landscape! And hopefully follow-ups will appear sooner than later.
-M.

globo’s picture

Sadly I can't offer any help on this matter. I just want to express my support for your request.
Documenthandling (especially for images) is so poor in drupal. A system that can rock the world in many aspects is not able to handle the most basic image publishing needs. I know there are many modules out there that try to tackle this problem. None of them seems to be able to do it the "drupal-way"
So right on. Strive for the perfect solution. Make documenthandling as good and easy to use as all the other features that make drupal on of the best out there.