Yes. The Bell Labs V8/9 vismon program (correct me if I'm wrong John), used
just 48x48x1 format. It used to request faces from a face server (like you
suggest below).
John Mackin and I have been discussing a few of these ideas off-line; perhaps
it's time to put our ideas to the list.
} 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:
There are problems with the current faces "database" structure. It uses a
ridiculous number of inodes (I suspect this could be a real problem to
some small sites). Unix directory lookup is not the fastest operation in
the world. There are a lot of formats supported. To be honest, I'd like to
get rid of sun.icon and 48x48x1 format, and just support face.xbm and (when I
get a round tuit) face.xpm format. This would allow us to easy handle mono
and limited color images. Greyscale and TrueColor images need to be thought
about at a later date. The NeWS version would also support face.ps files,
because animated icons are really cool! Reducing the number of file formats
would speed it up slightly, but a better database approach is really needed.
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.
Converting a large directory structure to .dbm format once a month seems
acceptable to me. The database would use only one inode. That would be
nice.
There could easily be in-memory hash lookup tables, and various optimisation
techniques applied if the dbm lookup was still too slow.
} - a face location daemon that could be asked for the appropriate face
} for the given user/host
This is in the spirit of the Real True vismon(8). I like this idea as well.
It doesn't limit the face server to being on the same machine, although if
some form of RPC was used for the dbm lookup, then there isn't that problem
there either.
} We should be ready for good performance with databases of hundreds of
} hosts and thousands of users (much sooner than we probably realize) and
} eventually thousands of hosts and tens of thousands of users. Unless
} X-face:s become more important than the on-line databases ...
Agreed. If/when I/we get all the bugs out of the looking up of aliases in
the people.tab and machine.tab files, then we'll need to improve their
handling too. There are also bugs in the handling of multiple face directory
structures.
Whatever solution is chosen, it'll be a fair bit of work to write and
implement. It's a project that could be done in isolation, then integrated
with the latest faces when it's found to be an acceptable solution. If
anybody wishes to volunteer to prototype some of these ideas, I'd love to
hear from you.