Subject: Re: faces performance issues & database lookup

From: richb@stard (Rich Burridge)
Date: Mon, 8 Apr 1991 17:43:30 +1000

} While I'm on the subject of X-Face, I like the -a flag and use it
} habitually, but I have a complaint.  If I get a second message from
} the same user the original face bitmap is used _even_if_ the second
} message includes a _different_ X-Face.  I like the idea being able
} to occasionally tailor X-Face to message contents.  I wish the -a
} option did not interfere with this.

Okay. I've just fixed this. Faces -a will now generate a new record (ie.
a new icon), for each X-Face:'ed mail message. It makes no comparison with
preceding mail messages with X-Face: lines from the same person; I currently
don't save enough information (ie. the X-Face: data) in order for that to be
possible.

---

From: Philippe-Andre Prindeville <[email-masked]>
Date: Mon, 8 Apr 91 14:21:54 +0200

> Date: Thu,  4 Apr 91 14:28:46 +1000
> From: John Mackin <[email-masked]>
> To: The Faces List <[email-masked]>
> Subject: faces performance issues & database lookup

> Hey!  Here it comes man!

>     } If so, have these alternatives been considered?
>     }   - a dbm database of face locations that can be searched faster than
>     }     the directory structures; or even loaded and kept in core by the
>     }     faces program for very fast searches; something would have to update
>     }     the database every once in a while

>     This is one of the ideas I really like. Here are some of my thoughts:
>     [...]
>     Dbm format would probably work. I seem to remember that DBM(3X) had some
>     stupid upper limit of 1000 records or something. I'm sure that can be
>     worked around; there are probably better database manipulation packages
>     anyway. I believe Henry Spencer and Jeff Collier put one together for C
>     news.

> I don't mind this idea, but...  dbm will NOT work, and ndbm will NOT work,
> and we have to remember that not all UNIX variants have dbm at all.  Both
> dbm and ndbm share Rich's ``stupid upper limit'', and it's very bad.  The
> relevant manual entry quote is this:

> [ ... ]

> The thing about this, though, is that it isn't conceptually clean.
> _Appearing_ to use the directory structure of the filesystem to
> represent the database is beautiful.  _Actually_ doing so is a
> performance disaster, as we have found out.

Hmmm.  You're overlooking one possibility:  using X.500.  There is
the server that comes in the ISODE package from M.T. Rose, et al.
Such a database would be an ideal place to put the data...  Otherwise,
people with YP (ahem, NIS) can use that (sigh).

-Philip