Implement a node<->image relation for branch 2 (with imagefield and so forth)

As i see there is a potential need to discuss this, i have open the ticket.

Why creating entitys for images?
1. The biggest reasons here is the storage of meta-data information. You could press them all into the image tag, using whatever, alt with some weired syntax like alt="name=value|name1="value" but this will not last long and is semantically pretty bad. The most important argument here is the dialog itself.

2. To load a image-detals form, where you can change such informations, needs you to pass those values by _GET. Why? because you can use ajax post to load the iframe. Technically this would be possible, but as we dont change the location.url then, its not a reload and all our css / js in the dialog wont be working and thats actually excatly what is so interesting on this dialog. We have a complete working bootstrap without hacking arround. Using entitys (use entries) i can pass a ID only (one get argument) all the other information is fetched out of the entity + entry

Why use a node as storage for that entity
Well this is the most argueable point actually. One of the biggest reasons here are the possible use of imagefield. This makes this node really handy. You can replace the image, and it will be replaced in all content. This also makes a new meta-data possible called "version" which lets you choose whether you want to link to the newest or exactly that version of an image. In addition you can use all the bulk operation and you share your code with one of the most spreaded modules (regarding to the usage statistics). So this would keep this module small, using modules which are very stable (imagefield, filefield)

Using imagefield lets us the use filefield getid3 later, to extract exif information

But the most important reason for that idea is the customization. So you can use normal alter methods, you can use the nodeapi and all that stuff to extend the meta information shown on the user interface in the dialog ( in the advanced field ). So this makes the module widely usabel. Also implementation where you can select a part of the image to be used are simpler possible then.

Well i see this point that this can become have, i mean using node as a storage. But yet i urgently see a need for those an entity in general. Iam very please to hear any arguments

Why do we need a additinial relation"image entry":
Well this is mostly because of even if you use a specific image entity at one place, you will probably change :
- which preset is used
- what style should be used
- whether lightbox should be used to show a big size image
- whether it should be version-sensitive or not
( - Title)

So those meta-data is use-specific. You can use a image several times, while using different meta data of those fields above. So eventhough we have an image-entity which stores all the hard facts like filepath, author, title you will need to have so a container, which stores the "use settings"

Where the heck should all this extra field go
Dont be scared, one of the most important things i care about is usabilty and simplicity. So the dialog will stay nearly the same as now, but will become a "Advanced" tab" which will present all this extra stuff. So the general user will not be confrontated with all those things.

Also things like id3, fancy cck fields and things should become submodules and dont need to be activated for every installation. So you can keep your usecase very small - if you like to.