Subject: Performance and faces architecture

From: [email-masked]
Date: Mon, 8 Apr 91 12:01 PDT

PERFORMANCE THOUGHTS:
    I  think the performance discussion is mixing implementation
with architecture.  The question about whether there should be a face
server type architecture is separate from how to do a fast face lookup.
It won't help performance at all if 1000 people are asking a face server 
for faces and it's doing 20 nami's for each face.

    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         [email-masked]
                                ...!uunet!littlei!adams