A lot of what Jamie suggests can now be done with the faces -e option, and
some clever front-end programming. An example of this kind of thing is Steve
Kinzlers newscheck perl script.
I think it's time to discuss the next step in the evolution of faces. There
has been previous discussion in this mailing list about dividing faces into
three:
1/ A faces image server. Given a user name and a host name it returns an
image.
2/ A set of scripts/programs. These monitor a queue (file, list, whatever...)
and from this generate a set of user and host names, which calls to the
faces server turn into the appropriate images.
3/ A display program. Takes the images, and displays them.
Even this is too restrictive. Jamie has come up with ideas that don't fit
into the user name and host name model.
We need to specify what each of these programs should do. A good starting
point would be to split off the image lookup part of faces into calls to
a separate faces image server and design, create and build that server.
My initial thoughts were that the faces image server should look(&feel) like
the Domain Name Server. There only needs to be one faces server for the
whole of the organisation.
Before I do off and "hack" up a prototype, I'd like feedback from the rest
of you, on what you think a faces server should do.