Subject: Re: New faces application & faces monitoring in general

From: "Steve Kinzler" <[email-masked]>
Date: Wed, 17 Feb 1993 14:30:10 -0500

Written 17 Feb 93 11:44:10 +0100 by [email-masked] in mail:
+---------- "New faces application & faces monitoring in general" ----------
| Hi,

| 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 [email-masked] these days.

| Regards,
| Axel.

| <[email-masked]>   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)\    [email-masked]
an organ with a mind of its own    \(o/

---

From: Boyd (Get in The Ring, ...) Roberts <[email-masked]>
Date: Wed, 17 Feb 1993 22:01:52 +0100

all i see here is a plethora of junk retrofitted into something that
doesn't even work correctly at it's _base level_ functionality.

and that's progress?

---

From: Jamie Zawinski <[email-masked]>
Date: Fri, 19 Feb 93 13:18:47 PST

> | symbol, that indicates that all info has been read.

I wrote something like this last year, but never quite got around to
finishing it.  It doesn't seem likely that I will any time soon, so I might
as well post it here.  (I sent this to Rich Burridge the other day, and he
said he'd have a look at it when he gets a chance, but maybe someone else
would be interested in hacking on it as well.)

"biffomatic" is an Xt program that reads from stdin and displays the images
that it is given on a window.  It can display more than one at once, and
manages an internal cache (with parameters settable at run-time) so that
it's really pretty fast.  It understands xbm, xpm, and faces.  It normally
is handed file names, but it can display an X-Face: line handed it on stdin
as well.

The idea is that some external program will launch biffomatic, and that
other program is where the intelligence for what should be displayed goes.
I hacked up some emacs-lisp code to do this, but that part is not quite
done.

 % ls -l biffo*
 -rw-r--r--  1 jwz         17617 Feb 19 13:11 biffomatic.tar.Z
 -rw-r--r--  1 jwz         24309 Feb 19 13:12 biffomatic.tar.Z.uu
 % zcat biffomatic.tar.Z | tar -vtf -
 -rw-r--r-- jwz/hackers 1588 Jul 14 17:09 1992 Imakefile
 -rw-r--r-- jwz/hackers 26684 Jul  3 18:50 1992 biffomatic.c
 -rw-r--r-- jwz/hackers  9193 Jul  7 12:19 1992 biffomatic.el

Enjoy...  Comments welcome.

	-- Jamie

---------- slice 'n' dice -------------------------- file: biffomatic.tar.Z.uu