Re: gmc associations

[James Smith <j-smith physics tamu edu>]

> -- Well, how can you do that (and keep it fast)?
> 
>   a) make assumptions based upon the filename - 1 I/O per directory.
>      Very fast.  Good for FTP/HTTP filesystems.
> 
>   b) open up the file and read it's data and then make assumptions
>      based upon magic numbers and so forth (ie "file" or LibDataType).
>      usually only 1 I/O per file, so not as fast as a).  Usually fast
>      enough for local and LAN filesystems.
> 
>   c) Keep data associated with each file containing the type of data
>      of the file (c.f. Macintosh).  This is out of scope of GNOME and
>      IMHO really stupid :) Still usually at least another I/O per
>      file.  Possibility of bung file types in this resource fork.
>      Again, stupid.
> 
>   d) Assume a), open the file and check for file type suggested by a)
>      first, otherwise use b).  1 I/O per file.
> 
> Or
> 
>   e) Use technique a) or d), based upon user preferences.  You might
>      specify a) for HTTP and FTP filesystems, but d) for local and NFS
>      filesystems.  NFS to server "turtle" use a).  If method d) takes
>      longer than 10 seconds, give up and fall back to a).

I like (e) - but on fast systems with lots of memory (like mine at home
and rainbow at work), once a particular area is accessed on a disk, it
can pretty well be assumed the surrounding areas will be in memory long
enough to do whatever reading is needed.  I would like to see a good
default setting for this, but have the ability to fine tune it through a
control panel - haven't thought of the details yet...

Maybe a matrix:
              filename    magic    smart
   Local
   NFS
   Network
      FTP
      HTTP
      etc.

   with settings for smart (as in option d above), dumb (as in options a
or b), and preferred order with an optional timeout before going to the
other.  I know this sounds a bit like (e), but I think it's a little
more flexible.  Maybe even have a system default that the sysadmin could
tune to the system.

Another problem we could have is people using their home directories
over a network.  We have a central file server (rainbow) which serves
out the home directories via NFS to canary and pine (both colors). 
canary and pine (and rainbow) are RH5.1 boxes, but canary and pine are
``smart'' X-terminals which run the programs locally with the home
directories served from rainbow.  Rainbow manages dumb X-terminals such
as NCDs.  It would be nice to have several different set ups that could
take into account what machine the person is using to access their
files.  One setting might be better for pine and canary than for
rainbow.
(Don't ask why we set it up like this - we just did.)

---------------------+---------------------------------------
Jim Smith            | Email: j-smith@physics.tamu.edu
Texas A&M University | http://people.physics.tamu.edu/jsmith/
Dept. of Physics     | Phone: (409) 845-1379
---------------------+---------------------------------------