anonymous (no@spam.com) on 1/31/09 wrote:
---------------------------
>>What EAs (however you store them) should be used for is things like state that
>>the program you previously used to look at the file wants to restore when you open
>>the file again (you were looking at this area of the image, at such-and-such a zoom level).
>
>Huh?
>
>Use a config file for that application.
>
>When saving an image, compute its checksum, and save that
>plus the desired config info in the config file.
>
>When opening an image, compute its checksum, look that up
>in the config file, and load the config info.
>
>Bonus points for using a text-based config file.
>
>No extended attributes needed.


As I mentioned, I was specifically not considering how the EAs were actually stored, just the sort of information that was proper to put in them. A separate database of some sort is certainly one approach, as would filesystem based EA or alternate data streams, or...

But your approach will certainly have scaling issues. I could easily see wanting to store data on many thousands of files, and a single text file will get pretty unworkable at those levels. Plus, using a checksum for a lookup means you cannot associate data with an updateable file (unless the program doing the updating knows about all the extended attributes that might be stored for the file).

If you're suggesting many small config files (perhaps one per target file), that raises other issues, like naming, cleanup, and pressure on the file system.