[development] nodeapi image concept (request for feedback)

[Darrel O'Pry]

On Mon, 2006-04-03 at 22:47 -0400, James Walker wrote:
> 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 think I can be persuaded to the node-level file concept. I'd really
want to hear ideas about asynchronous node creation, node/filesystem
consistency, loading data about 10's-100's of files at once (file
browser), flexible attributes table... (specific to files or to all
nodes?, like old serialized storage but queryable), clean handling of
preview states with file nodes.(I'd personally like to remove the
concept of a file preview altogether, you either upload it or don't. I
don't like 'file limbo' and I think it is a confusing UI and development
paradigm. Look at the hoops we currently jump through to support files
in previews, and the difficulties it has caused with validation and
open_basedir that could be completely eliminated by removing the idea of
a file in a preview state.)

It would be nice to take advantage of the existing node_access system
and nodeapi. It would also bring more focus on making a node a universal
concept. 

I would also like to have files owned by users and simple associated to
a node, which is implicit with the files as a node concept. 

> I've given my thoughts on this several times, but need to sit still long 
> enough to write it all down.

I'd really appreciate the input if you can find the time. I keep putting
thought into this, but I am undertaking the effort for my own projects.
I would like the work I do to be useful for the community as a whole and
not be limited by my shortsightedness and focus on my own goals. 

.darrel.