Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!ATHENA.MIT.EDU!raeburn From: raeburn@ATHENA.MIT.EDU Newsgroups: comp.mail.mh Subject: Re: XMH cache Message-ID: <9008231932.AA07683@PROMETHEUS.MIT.EDU> Date: 23 Aug 90 19:32:45 GMT References: <9008231028.AA18521@rodan.acs.syr.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 64 > Date: Thu, 23 Aug 90 06:28:44 -0500 > From: "Jerry Peek" > The .xmhcache file basically just holds the output of 'scan -width 100' > for the folder. (The width comes from the TocWidth resource entry.) > A simple-minded fix would be to run a program that compared the > last-modification time of the .xmhcache file in a folder to the messages > in the folder. If any message is newer than the .xmhcache file, the cache > needs rebuilding. I'm not sure I understand your filesystem and network > setup, but I'd bet you could do the rebuilding on the host where the > folder lives... then copy the new .xmhcache file to your local host. Too simple. That won't catch messages being deleted or refiled from the folder in question. (Regarding the file system: With AFS, files aren't stored on the server as a normal file system, so logging in there -- even if I were permitted to log in to our dedicated file servers -- would not be useful. Files are, I believe, entirely brought over the net, into a local file cache, before you can start reading them. It actually may be a bit more efficient than that; it might only take 64K chunks of the file or something, I'm not certain. It winds up being reasonably efficient for a lot of things, but "scan" is not among them.) > If xmh was running at the time, though, it wouldn't know that the .xmhcache > file had been updated -- so, the Table of Contents display wouldn't be > updated. This fix would probably only work when you're *not* running xmh. Good point. I'm not sure how this would be best dealt with, but xmh could be coerced to re-check that file periodically and any time it had "interesting" operations to perform. BTW, my idea is to put a cache into MH, then modify xmh to use it, not to make MH use the current .xmhcache. I'd want a little more flexibility in what information is retained. I would also expect it to be a compile-time option as well as run-time (when enabled), so that sites that are actively disinterested (i.e., don't want to permit their users to use it) wouldn't need to waste the code space. > > Does anyone else think it > > would be a good idea for an addition to MH proper, as an extra > > option (preferably runtime-selectable, I'd say)? > > No. Because MH is a bunch of separate little programs, it's easy to use > in shell programming. I think a short shell script that runs 'find -newer' > to compare the messages, then does the 'scan', should just about do it. A runtime-selectable option probably would not inhibit use of these programs in shell scripts. If you have to do a lot of message reshuffling, one message at a time, just disable the cache, and rebuild it later. Even if you didn't explicitly disable it, it'd just make things a little slower. For larger jobs like gnuemacs mh-rmail does, you'd probably want to use the cache update, since you'd (I assume) be moving (or deleting) lots of messages with a single command. The "find -newer" solution is, as I mentioned above, too simple. The best way I can think of to do it with this approach (and what I believe xmh does) is to check the modification time of the folder, and rebuild the entire cache if the folder is newer than the cache file. Because the MH commands are the only place where it's really known exactly what's happening, I think that's the only reasonable place to put this cache management.