Musings on an Erlang GUI System.

[Bob.Smart@REDACTED]

> want the GUI to run on one machine and I want the control 
> process to run on another machine - if we wrote them like 
> this then we could write wonderful apps - spawning of GUI's 
> on remote machines etc.  great fun ...

If we're going to do GUIs and get them right 
then we need to get security aspects right 
as well. Some of the important issues are 
discussed at www.erights.org - see the "secure 
interaction" pointer under "what's new". 
Basically it is crucial that the user can 
distinguish "safe" windows produced by the 
users own machine(s), compared to windows produced 
by processes which, though they may be acting 
on behalf of the user, are coming from software 
not under the user's control - e.g. web pages. 
Otherwise the user is in danger of screen-spoofing. 
That's what "untrusted java applet" is about, 
but we need a much better system than Java's 
all or nothing approach.

So it is important to distinguish: screen, client, 
server.

                2-way                     2-way
    screen <-------------> client(s) <--------------> server(s)
    (user                    (user                    (foreign
   control)                 control)                   control)

Clients need to be clever enough to coordinate 
(near) simultaneous input from the server and 
from the user/screen, modifying the state which 
needs to be displayed to the user. However the 
screen shouldn't make sudden changes that induce 
the user to make unintended input (e.g. click on 
the wrong item). Also the screen should react 
immediately to input: don't you hate it when you 
click on something and nothing happens so you 
click again then that window disappears and your 
2nd click does something else in another window...

In terms of the two way communication between 
client and server: there are various requirements, 
a key one being that there can be processes 
waiting at each end for new information coming 
from the other end. At the very least if you are 
thinking about how to do this you should read
http://www.beepcore.org/beepcore/docs/rfc3117.html 
on "The Design of Application Protocols", even if
you think that the resulting BEEP design is overkill.

Bob