Re: Icons of program

[swittams cix compulink co uk (Simon Wittams)]

In-Reply-To: <199804212156.XAA06918@bofh-home.gjt-it.nl>

> I have been playing with large datasets in MySQL lately and it is a likely 
> candidate to be used; if the access to the db would be SQL, any SQL db could 
> be used, I would feed all our hosts to MS SQL until it choked ;-).


Erm....MySQL is doubtful, as unfortunately it has a non-Free license under the DFSG. 


Anyway, this would add huge load to the system, as it would have to do a load of 
searching about just to get an *icon*. And unless it was tied in to the linux VFS, 
which would add even huger loads, command line utils would either have to all be 
rewritten, and wouldn't work on not GNU-systems. 

I still think the best idea without changing the whole filesystem is mime-types ( based 
on magic numbers/ regexps of file names) for normal (data, libraries) files, and stuff 
added onto executables. 

Also, I think that on filesystems open to change, eg ext2, reiserfs, some use of 
extended attributes could be used. How big can they get, currently? 

It should be possible to make a file return a struct with all pertinent information 
whatever the method of storing that information. Therefore, as almost everybody is 
opposed to both registryish monsters and proliferating, regexp breaking, .info files, 
these methods should only be used if something better ( ie extending the fs ) can't be 
done. As long as changing the fs doesn't change how old apps see it, it seems like it 
should be done. It strikes me that everybody is suggesting half-solutions, trying to 
kludge existing standards to get it to work. I think it would be better to have a clean, 
proper way of doing on systems that allow it, and only kludge with funny .info files or 
extra trees or databases when you have to. I think the .info files are probably easiest 
to implement ( after magic/extensions), so they should be done first. But it should be 
possible to eventually have a non-kludge solution.

Rob