| Below follow some ideas wrt faces, discussing the use of
| faces for dynamically monitoring processes, and proposals
| that make faces more 'powerful' for that purpose.
| Maybe this is something for the list.. if you think so,
| please forward it.
I do, and will. You've identified critical issues that need to be
addressed for future faces development, and I think your suggestions are
sound. I understand Rich has plans to divide the faces functionality
into three components in future releases: a display manager, a database
server and an application. When that happens, these issues will be
especially pertinent.
| I have been working on a faces application, that links 'faces'
| to an Irc (Internet Relay Chat) client.
| Irc is a real-time conferencing system, a sort-of multi-user,
| multi-channel talk. The discussions are 'grouped' in so-called
| channels, a user can participate in discussions on several channels
| at the same time.
| The irc-faces 'program' can display a faces window for each
| channel the user is on, displaying a face for each 'participant'
| on the channel. The windows are automagically updated - whenever
| someone joins or leaves a 'monitored' channel, the corresponding
| window is automatically updated.
| If there is interest for this particular program, i can send it.
Sounds interesting. I can place a copy in the faces ftp archive, if
you'd like.
| For the implementation i use 'pseudo-mailboxes' that are monitored
| by faces programs - for each channel a faces-program is started,
| that monitors a pseudo mailbox. The pseudo-mailboxes are updated
| by the interface part 'linked' (via a pipe) to the ircclient.
| One of the problems with this interface is that the faces programs
| use polling to check for changes in the (pseudo)mailbox files.
| It would be interesting if faces could be made to check the mailbox
| in response to a signal - in that case there would be no need for
| polling; the interface program just sends the signal to the faces-
| program that monitors a pseudo-mailbox, after it has been updated.
| The key point is that i want faces to update its information, and
| i have the information at hand, and i know the process number of
| the faces process (the program that ahs the information is the
| one that started the faces programs)
| all that is needed is a way to pass the new info to the faces process -
| if files are used, it would be sufficient to be able to tell faces
| that it is time to re-examine the file.
| Such a signal-responsiveness would also be interesting combined
| with the -e option: in that case the signal would cause the faces
| program to re-invoke the program.
| This would make it easier to use faces to monitor processes
| without polling overhead, and without having to use the mailbox
| trick that i use in irc-faces.
Yep. It'd also be nice to have -e program reinvocation by user request,
such as typing a particular character in the faces window.
| Another interfacing possibility would be via the stdin of the faces
| program:
| have faces read from stdin (eg. in the format for the -e option),
| and have a special 'end-of input' symbol, or rather 'display-it-now'
| symbol, that indicates that all info has been read.
| Or, in the header, next to the Cols and Rows settings, before the
| faces information records, indicate how many records will follow.
| In that case, the faces window could be updated by writing a new
| set of records (followed by a 'display-it-now' record) to the faces-
| stdin.
| Another problem with the current irc-faces program that it gets
| slow if a large faces window (say containing more than 10-15 faces)
| needs to be updated. More generally:
| Because in most cases (at least in my application) only parts
| (small parts) of the faces window needs to be updated (eg only
| one 'face' is to be added or removed) it would be interesting
| if faces would work as incrementally as possible: it only gets rid
| of a superflous face, or reads the data for the new one, without
| re-reading face bitmaps for faces that are not changed (even if
| the text that is to be printed with a face changes, it would not
| be necessary to reread the face bits themselves..)
| (For this kind of dynamic monitoring _speed_ is very important)
| Maybe this is already implemented (I didn't check the code)..
| Some sort of 'caching' like this would not only be interesting
| for the mailbox interface, but also for the -e interface
| (when it is made to re-excute the program on a signal),
| and the proposed stdin interface.
| I hope there is something useful among the ideas presented above,
| I wouldn't mind to invest some time to (try to) implement (some of)
| those ideas, if people would think they might be useful, but i thought
| it would be better to have them discussed before i start to hack
| faces - if only to allow some coordination of the work on faces.
Go for it! The bitmap caching optimization could be immediately
useful.
Rich Burridge leads the development for faces. You should be able
to reach him at richb@stard.eng.sun.com these days.
| Regards,
| Axel.
| <Axel.Belinfante@cs.utwente.nl> tel. +31 53 893774 fax. +31 53 333815
| University of Twente, Tele-Informatics & Open Systems Group
| P.O. Box 217 NL-7500 AE Enschede The Netherlands
| "ili ne sciis ke estas neebla do ili simple faris" -- Loesje
-- from the brain of Steve Kinzler /o)\ kinzler@cs.indiana.edu an organ with a mind of its own \(o/