Well, as the person who changed faces to have the heirarchy in there I
must disagree. Faces is for displaying the icons associated with people
in the network. Now, the way these people are identified is through
their network address. Until we have an efficient X-500 service then a
person's login name is their best form of identity.
Now, since network names are a domain based heirarchy it seems best to
have the faces stored in a similar heirarchy. Since UNIX already provides
this for free (the file system) it was a natural, and widely available
choice. The reason we search up the heirarchy is that a person can thus
easily cover a large sub-domain (for people who move between machines in
a department etc, just put your face at the departmental level),
so, for example, I can be reached as
rex@cs1.cs.su.oz.au
rex@karl.cs.su.oz.au
rex@basser.cs.su.oz.au
rex@ugrad.cs.su.oz.au
rex@cs.su.oz.au
rex@su.oz.au
(and once apon a time rex@oz, but these things change :-)
So, My face appears in the local heirarchy as rex@su.oz.au which is the
most generic name for me. If there was to be a more specific rex,
say rex@random_machine.cs.su.oz.au then a new entry would suffice in the
full domain specifier. This reduces the number of entries, and maps very
nicely, thank you very much, onto the real world, which is what we are
actually trying to map.
> 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.)
This is a pretty tall order. You have a lot of mappings here, and are trying
to implement most of X-500 for the local domain. I'd love this sort of
generality, but it is hard to achieve, and retain some sort of efficiency.
> 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.)
But do you not wat it on delivery of mail? Or does your mail reader scan your
mailbox for new mail? In that case you have a duplication of scanning between
faces and your reader. My mail reader is very dumb, and is little more than
more on mail boundaries (I like it like that too). So having faces scan the
mail box is a nice option. It also means I don't need modifications to the
mail deliverer or the mail reader.
> 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).
If your address keeps changing (at the local level, or at the global level,
ie your address from this message is
Jamie Zawinski <jwz@lucid.com>
What changes? lucid.com changes, or jwz changes? In eithercase I'd say this
is a problem with your administrators. Consider your network address like
a postal address. It is annoying when that changes, and has similar
ramifications.
> 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.
Whilst I think these would be a good idea, I disagree that these should
be in the mail reader. I want a mail reader to read mail, not to tell me
about the time, or the weather, or anything else.
I'm also of the opinion that these would be better handles by a change to the
X-Face line of the mail item. I share a room, and we share a telephone line.
If one person sends a message "from the telephone" they use a different
X-Face line, and I know where the message is from before I read it.
> 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.
My opinion on EMACS cannot be broadcast on a public network. I'm from the
old 'tools' school, not the new put it in every program and make it run
lisp school (call me a fuddy duddy I suppose)
> 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.
NO NO NO. The X-Face should NEVER be stored in the database. See above,
the X-Face from a person can change according to the message type, if
you want to change the "default" icon for yourself that is an explicit
action, and should be done explicitly.
> 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.)
DNS takes approx 20% of the bandwidth of the network in Australia (the
only place I have data for).
> 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.
But why? Why not grab the faces you want, and keep them. Faces don't change.
It is far more efficient to have small messages for infrequent occurances
(a face changes, you know, you were in a disfiguring car accident etc..)
than for the common thing (getting the same data over and over and over)
> 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.
elisp? One monolithic program relinking on each invocation?
> Anyway, just some thoughts. You may flame at will :-)
>
> -- Jamie
Just some replies..
Rex.