I think that faces is a wonderful idea, but I find the current
implementation a bit too restrictive; and there's something I really don't
like about having to use the structure of the file system as the database
tree, though I can't put my finger on it. (Aside from efficiency issues,
I mean; I've got a problem with it aesthetically...)
Anyway, here are my thoughts on what features I would like to see. These
are just some design ideas pretty much off the top of my head; I'd like to
know what others think of them. (I'm not terribly familiar with "faces", so
perhaps it already does some of this and I haven't noticed. I'd like to
know if that's the case!)
I'd like to have a program which takes as its input a list of "keys" to
display. These keys could be hostnames, usernames, whatever, and the
program would consult its database, and pop up the corresponding picture.
(This would essentially just be the output part of faces; the smarts would
be elsewhere. A mail-checker would integrate with this in the obvious way.)
I would then modify my mail reader to send a command to this program each
time a new message was selected. In this way, I could have a small window
always displaying the face of the sender of the current message. (Since I
use VM inside Emacs to read my mail, this would be pretty trivial to do.)
My newsreader (GNUS) could also be trivially extended to display a set of
bitmaps corresponding to the sender of the current message and the
newsgroup(s) in which it was posted.
The keys should be a list of alternatives. I think that email addresses are
a bad way to index faces; they're good for company logos, but not for
people, because individual addresses tend to change at the whims of the
system administration staff. So for each message I would send a list of
keys to be tried in order until one matches; in this case, the list would
be just the user's full name (for the user's face), followed by their email
address (for the organization logo if there's no user-face).
But I would like to use other things for keys besides names and addresses.
I would like to have different icons depending on the contents of various
header fields, like Subject, To, CC, Delivered-By, and so on. I would like
to see different icons based on any of the following conditions:
mail on a topic
mail from the "vacation" program
mail to a particular mailing list that I am on
mail to a mailing list that also includes my name in the To or CC line
It seems to me that all of the smarts for this sort of thing should be in
the mail reader, but maybe that's just because I use a mail reader that's
very easy to customize.
I think that doing this for message selection is really just a "cute hack";
what I really want it for is so that my mail-checker can be implemented in
emacs. Interfacing something like "reportmail" (with its concept of "junk
messages") with a program that could display a set of bitmaps (instead of
just one, as xbiff++ does) would be ideal.
I'd like my mail-checker to display multiple rows and columns: one axis
would be messages, and the other axis would be triples of the bitmap
corresponding to the sender, the bitmap corresponding to the sender's
organization, and a bitmap corresponding to the message topic (if any.)
I'd also like the window to dynamically change size, or perhaps unmap
itself when it was empty. It shouldn't consume screen real-estate when
it has no information to offer.
The mail reader should be responsible for noticing X-Face headers and
invoking another program to store them into the database. Alternately, it
should be possible for the mail reader to just send the X-Faces data to the
display backend directly, without storing it in a database. If the display
backend kept a cache (say the last 100 images shown or so) this would be
pretty efficient.
It might even be fast enough to have the appropriate face pop up as the
mouse moved over a message.
On the implementation side of things, I'd like to see a setup where there
were a few face-servers on the net, and a local database at each site
running faces. The local database would be a cache; it would consult the
server only when there was a miss (and it would cache misses too, with a
timeout of a few days.)
If you think about it, this is exactly the same as having every user of
"face" ftp a new copy of the bitmap tree from iuvax every couple of weeks,
but more efficient, and more to the point, automated.
With a cache in the display backend caching to optimize away access to the
database, and a cache in the database to optimize away access to the
network, this thing could really fly.
This modular approach means that folks who only wanted to use a handful of
bitmaps, or only wanted to use X-Face headers, wouldn't even have to install
the database part. Alternate mailbox checkers, layout algorithms, window
systems, etc could be played with without having to re-link one monolithic
program, or add new command line options. And even better, you could do
any part of it as an elisp client.
Anyway, just some thoughts. You may flame at will :-)
-- Jamie
PS: I'm the fellow who added the faces-like features to xbiff++, though
these days I think that xbiff++ is way too limited as well. It has some
features that I really really like, which is why I'm still using it, but
faces does a lot more.