Re: FACEPATH problem - finding the best match

Steve Kinzler (
Tue, 15 Oct 91 12:58:56 -0500

Written Oct 15 by, in mail:
+---------- "FACEPATH problem - finding the best match" ----------
| The `faces' manual entry claims (faces version 1.5.6):
| To access the face for the mail name machine.dom.ain!uid take the
| result of the first successful open from the following list of files
| (where $DIR represents iteration over the list of directories in
| $DIR/machine.dom.ain/uid/iconname
| $DIR/dom.ain/uid/iconname
| $DIR/ain/uid/iconname
| $DIR/misc./uid/iconname
| $DIR/machine.dom.ain/unknown/iconname
| $DIR/dom.ain/unknown/iconname
| $DIR/ain/unknown/iconname
| $DIR/misc./unknown/iconname

Yes, this is rather unclear. Nonetheless, I have always understood it
to work the way the code is really implemented, and this is the way I
think it should remain.

| [1] for (id = 0; facepath[id] != NULL; id++) {

| [3] path = (chdir(facepath[id])) ? facepath[id] : "." ;

| [2] for (iu = 0; iuser[iu] != NULL; iu++)
| [2] for (ic = 0; icomm[ic] != NULL; ic++)
| [2] for (cptr = icomm[ic]; cptr != NULL; cptr = index(cptr, '.'))
| {

| If, for example, in one facedir we have
| $DIR1/
| and in another facedir we have
| $DIR2/

| Depending upon the order of $DIR1 and $DIR2 in the FACEPATH
| will be matched with the first or the second face.xbm.
| Thus, if $DIR2 precedes $DIR1, the `incomplete match'
| $DIR2/
| takes precedence over the `complete match'
| $DIR1/

On the other hand, we have
since my face is the same on all the subdomains (cs,ucs,cica,etc) &

Now I intentionally put $DIR1 (local) ahead of $DIR2 (logos) so that
I see my face and not the default department logo.

Another reason to leave it as is, is that changing the order of the loops
would make the algorithm less efficient since the overhead of changing
face directories ([3]) applies once for every lookup attempt instead of
once for every face directory. Right now, this overhead is low, but I
can envision something like having a hashed index of a face directory's
contents in each face directory for fast lookup instead of using the
filesystem (something I'd like to implement if ever I find the time) --
then the overhead (opening and closing the indices) becomes significant.

I think with a functional seperation of face directories and consideration
to their ordering, problems such as you describe can be avoided.

from the brain of Steve Kinzler /o)\
an organ with a mind of its own \(o/ {ames,rutgers}!iuvax!kinzler