Re: GUI's and the Rouge, Part III (yes, finally) 1/2

Tom Sawyer wrote:
> wouldn't really consider writing it all from scratch.

cool, just so you know.

> rich asynchronous message passing. does it really need to be that
> "fancy"? perhaps. the communications layer is optional, but i tend to
> think standard tcp/ip + marshaling might do the job.

Actually it isn't much more than tcp/ip and marshalling, until you get into
the distributed object issues. The key thing here is that behaviour inside
the GUI is also controlled by async msgs - every key up/down, every mouse
up/down/motion is a message which is dynamically matched against message
handlers on the objects - so messages act like a delayed dynamic procedure
call with re-routing. If an object has no handler for a message, or the
handler returns false (saying "handling not complete"), the message is
propagated up to the parent and tried there. When/if it hits the session
object, if that session object is one end of a connection, the message is
marshalled and queued for transmission.

Re publish/subscribe, before a message can be delivered to an object, a check
is made whether any descendents of that object are listening (subscribers) on
that object for that message or one of its superclasses. In this way a GUI
main window can be set up to receive a message containing all the data values
required to fill out the fields, and the individual widgets subscribe to that
message on the main window, so that the message is delivered to each of them
before being delivered to the main window object itself. That solves the
scatter part of the scatter/gather problem to be solved with the main window
even needing to know which widgets display which data fields.

The distributed object system is maintained by the marshall process, which
turns any object reference from a pointer into either a "local reference" or
a "remote reference". A local reference corresponds to a local object which
is being exported; the reference is maintained in a table of exported local
objects. On the other end, each local reference received from the other end
gets maintained in a table of proxy objects. When marshalling messages in
return, a pointer to a proxy object gets turned back into the original local
reference from the other end.

In this way, any number of objects spread across arbitrary networks of
point-to-point nodes may be addressed without requiring a UUID scheme, and
any message targeted to any object will be routed back via the connection
from which that object became known. BTW I don't know if anyone else has
invented this scheme or patented it, but I do know that I now can't :-).
It's an exceptionally powerful distributed object paradigm.

> > The native GUI widgets should be assembled into hierarchies not by API calls,
> > but by a hierarchical description language - XML probably.
> well, i disagree here. i thought about that option: whether the models
> should be in markup versus executable code.

The executable code in OpenUI is nearly all in the form of "when" clauses,
which are the message handlers. They're not used for non-UI things though,
in fact despite having a rich O-O language with a VM and fast compiler
interpreter (very similar to Java but on the market six years earlier),
it deliberately doesn't have any local O/S access and no external extension
mechanism. You have to write message handlers in native code (C, Pascal, Ada,
COBOL), which are registered at the session level on either the front or
back end.

> I'm interested to know more about OpenUI and if you should decide that you
> could contribute to the project please let me know.

Hopefully I've satisfied some of your curiosity.

Probably can't contribute much more at this stage, but someday I do want to
rebuild OpenUI's features, using someone else's XP GUI toolkit and preferably
someone else's compiler/interpreter. The async messaging and distributed
object system I expect to need to rebuild myself, though many vaguely similar
things exist.

> tkxml.rb

Will play when I get time.

--
Clifford Heath