I've got part of that already working, and I'm about half-way into the larger mod (see my other postings).
I need to discuss with Alex how to add features to the Admin screens, since any "procedure" should be "official" and have "hooks" to allow plug-ins to access them (ie: not hacks to files).
My goal (for my own needs) is to have the ability in the admin to upload a file, specify a directory, create a thumbnail and move the file. This is part of the picture-post/gallery mod. In the admin, I'd like the thumbnail to show as part of the admin record, with links to the full record and images. Again, this has to come from Alex eg: how to do it. There are all sorts of ways, but with Links still in beta, and the version 1.o of the 2.o release coming, there are going to be loads of changes, and hacking code files with each release is not going to be fun. A "plug-in" way of doing it is much better.
(GT has directory and file management utilities that I'd like to see built in to links in a similar way MySQLMan is. That way, the whole links tree can be built under the server ID, and it can be managed via the Admin.)
The current program 01.01.21 allows one graphic file to be uploaded to each link. It has the possibility to be expanded beyond that.
The 02.xx.xx version will allow multiple file attachments, but requires a more sophisticated management scheme similar to the CatLinks file to do it right.
The current 01.01.21 version is $25. The 02.xx.xx version described I don't know the costs yet since I don't know everything it will take to develop it, and maintain it (support). I do know the thumbnail/manipulation routines took the better part of 100 hours to get working via CGI without Image::Magick.
The photo-gallery/picture-post mod is going to be about $250, since it's going to be a fully functioned application, and will require continual development, so the multiple-file upload will be somewhere between them, but figure at least 2 weeks for development, since there are many, many things that need to be taken into consideration -- not the least of which is maintennance (garbage collection), error checking and catching, and coming up with a workable organizational scheme that migrates upwards as the site (and collections) grow. One idea is to tie directories to categories, and/or links themselves to directories, but then managing the relations between the database record (virtual file system) and the physical disk (file system) becomes increasingly complex.
This is a thing I've been thinking about since 1984 there-abouts, back in the dbaseII days.... Technology and tools have advanced a lot since then, but the key to image indexing is still the database design and that is still a big problem.
PUGDOGŪ PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
