[development] nodeapi image concept (request for feedback)

[James Walker]

On 4/3/06 3:34 PM, Darrel O'Pry wrote:
> On Mon, 2006-04-03 at 09:36 -0700, Boris Mann wrote:
>> On 3-Apr-06, at 9:28 AM, Sean B. Fuller wrote:
>>
>>
>>> But like I said, after considering all the management interface  
>>> that would be needed to really make multiple images work, it seems  
>>> like trying to pack this all in to image.module might be a bit  
>>> much. I'd rather see the nodeapi_image functionality that I posted  
>>> added to image.module, and then start a new thread about how to  
>>> effectively make an embedded multi-image mini-gallery in a node.  
>>> That's my two cents anyway. Thoughts?
>> The use cases for multiple images per node are many -- and "mini  
>> gallery" is only one of them. This is indeed a case for  
>> relationships, which is a higher level issue.
>>
>> Gerhard's upload_images.module associates multiple images, but only  
>> displays as thumbnails. Nodeimageblock doesn't use image nodes, but  
>> just upload files, and doesn't do resizing. My dream module would be  
>> a combination of these two, using 4.7. region to display the block of  
>> images (with configurable thumbnail size), displaying the image node  
>> title/caption and linking to a full size image.
>>
>> --
>> Boris Mann
>> Vancouver 778-896-2747 San Francisco 415-367-3595
>> SKYPE borismann
>> http://www.bryght.com
> 
> I'm still hot on the idea of a file callback that works with the
> existing upload.module, and eliminating all this image.module,
> audio.module, media.module stuff and having plugins that react to the
> file lifecycle based on mime or extension....

well... yeah, I mostly agree with that. I think a lot of the "smarts" 
for file handling need to be offloaded into core's File "API". However, 
I disagree that this is instead of image/audio/etc . But I think 
image/audio/etc shouldn't have to do so much.

But, back in the day I was trying to promote the idea of "toolkits" 
(which you call here "plugins") ... for exactly this reason - extracting 
metadata, additional file handling, etc.

> Still haven't decided whether a full-on node (utilizing existing nodeapi
> and all the weight of node_load) or keeping files as a distinct object
> from nodes so they can have a lighter api and making a file<->node
> relationship module. I'm going to try the former first.

I think we still want nodes-level "files" ... but yeah, "direct" access 
to the files is absolutely required... however, there are *many* use 
cases where throwing out all of the "for free" features of node-level 
stuff seems silly.

I've given my thoughts on this several times, but need to sit still long 
enough to write it all down.
-- 
James Walker :: http://walkah.net/ :: xmpp:walkah at walkah.net