slacker (s@lack.er) on 1/30/09 wrote:
---------------------------
>Put each picture in to a folder with an individual location file?

This is essentially what we do. (We don't create a new folder, just create another file with the same name and our own custom suffix to store the associated data.)

The Amiga did the same thing with .info files storing the icon and other information for the file with the same name (i.e. the icon and other info for file abc was stored in abc.info), while the Macintosh had a single file with a "data" fork and a "resource" fork for doing the same thing.

Our software only works under NT-based OSs, and NTFS is fairly ubiquitous, so we could have used streams to store the same information but chose not to because using this scheme:

1. The associated data is visible to the user. They can easily manipulate it (e.g. delete it) in Explorer or zip it up and send it to us to identify a problem. (We don't always need the original data, just the metadata.) It's easy for them to understand that if they rename a file they need to rename the associated metadata file as well, and it's right there in their face so harder to ignore. (On the Amiga, if you renamed a file using Workbench it renamed the .info file, too; if you used the commandline it didn't. It would be cool if there was a way to hook into the OS to tell it that you wanted an association between the two and that standard operations like rename should apply to the associated files.)

2. There are no surpises. If they back the data up onto a network server or USB key or FAT32 volume the metadata isn't going to mysteriously vanish.

The downside: twice as many files, and it's aesthetically unappealing. In your case you could end up with a large number of different files associated with each original file.

But it's simple, and it works.

There isn't a perfect solution. I don't like the database idea because the user can't see why renaming a file might break things[*], and it's a lot harder for them to extract the metadata to send it along with the file than having them simply send both files.

[*] One thing that was cool about the original Macintoshes was that every file ever created on a volume had a unique ID associated with it that could be used as a key in a database, rather than its name. There were problems (e.g. a busy disk could run out of IDs preventing you from creating any new files -- I think they were 32 bit) but I think the idea is good -- a unique and permanent identifier that the user couldn't (easily) change. You could move e.g. Word into any location you wanted and the OS would still launch it when you double-clicked on a Word document because the identifier was used to find the application, not the path and filename. (You could install Office just by dragging the folder from the CD onto the hard drive as well; Finder would look at the resource forks of the applications and immediately know e.g. what to open Word documents with.)