We have to solve both problems. The server concept just because
we can't have every workstation with megabytes of face database, and
performance because the database is large and growing and more people
wish to use it.
POSSIBLE ARCHITECTURE:
As to the client/server model, I have been having some thoughts
on how to add this to the existing 'faces' application. A redoing
and modularization of the interfaces in 'faces' is called for.
My current idea is:
|---> ...
|
| ---------
| | local |
|--->| X-face|
| | DB |
| | ---------
------------- | |
|application| | -------- -------- | ---------
|generating | | | | | DB | | | "old" |
|lists of |-->|->|cache |-->|switch|-|--->|face DB|
|name/host | | | | | | | | |
| pairs | | -------- -------- | ---------
------------- | |
| ---------
| | GNU |
|--->| finger|
| DB |
^ ^ ---------
| |
| +- General DB module interface
+- Interface that maps name/host pairs to icons
Thus, adding access to a vismon type face server would just be
writong another database module and linking it into the application.
Good points of this interface architecture:
-- separates the data application from the lookup function
-- could use the lower DB end to easily make a "face widget"
-- one place for a cache so lookups are not redone
Problems with this interface architecture:
-- the icon fetchers must have some knowlege of the applications'
display. Or alt least it's requirements for displayable icons.
(NeWS? color? resolution? ...)
-- the DB handlers must have some knowledge about "search sessions"
to know when to re-read configuration (alias) files
-- top level interface is bound to "name/host" pairs. How could
one generalize it to accept X.400 addresses?
-- Robert Adams adams@littlei.intel.com
...!uunet!littlei!adams