Re[2]: [Octal-dev] porting thoughts

[ccastiglione]

Author: "Bullwinkle J. Moose" <address@hidden>
Date:       6/15/00 1:10 AM

>How difficult do you supose it would be to create multiple GUIs for Octal?
>... is there any thing that can be done to the rest of it to make it 
>easier to create UIs for it?

Where I work we need to support multiple hardware clients and so we use an
architecture something like what Avelino was describing.  GUI's are generally
decoupled from the rest of the functionality using a client-server approach,
where a messaging mechanism is used to communicate between each GUI client and
the associated server application.

Of course this requires more coding overhead up-front (because you need to
support a message API for all UI operations), but if it's carefully done the
increase in flexibility is enormous.  You can completely replace the UI without
any changes to the server.  In fact, since the server is a separate executable,
you can replace the UI without even recompiling!  It also means that the UI
doesn't even need to be running on the same machine as the server.  I believe
jMax uses this strategy.

Octal would require a message bus interface on the server side to accept UI
messages and call the appropriate Octal functions.  Then the GTK interface would
involve sending messages when a callback is invoked, instead of directly calling
the equivalent Octal functions.  Of course, the other advantage to this approach
is that the UI doesn't have to be GTK;  any UI that is coded to know the
appropriate message formats can be substituted:  GTK or Java or TCL/TK or Visual
Basic or even a text-based UI.

Of course I'm not trying to undermine the goal of an end-of-summer beta with
this idea, so it's possible that an in-process GTK UI would be fine for now, and
the idea of a message-based interface can be explored later.

Just throwing out my own 2 bits.

Chris