Re: [Config4gnu-developer] brainstorm of interfaces

[Peter W. <wie...@we...>]

On 13. November 2002 17:21 wrote Jason Long:
> Last night I thought more about what kinds of interface, i.e.
> representations of the data, we might pursue. Here's my list:
>
> [...]
>
> What others are possible?
> [...]

I think it should be
=09a client server protocol
=09extremely simple
=09fast
=09low level IPC, not over the network.

There should be only one interface which is the basic and definitive
CFG interface. All other interfaces are layers ontop of this.
These other interfaces are
=09meta interfaces like CORBA
=09adapters for other applications like ODCB
=09transport protocols like TCP/IP.

Let me describe how linuxconf does it (linuxconf has 3 years of
experience and 80,000 lines of code) :
Linuxconf uses two pipes (one for each direction) to talk
between the UI (called "GUI server") and the conf program.
They send simple ASCII text with primitive XML style frame
containing a shell like command line.

A short quote [(C) by linuxconf developers, fair use, blabla] from
their docu:
---begin of quote
=09Here is an example of a small dialog:

=09<tscreen><verb>
=09MainForm basic "Basic menu"
=09    Label "Your name"
=09    String S1 15
=09    Newline
=09    Label Telephone
=09    String S2 15
=09    Newline
=09    Label Status
=09    Radio R1 1 0 single
=09    Radio R1 2 0 Married
=09    Newline
=09    Button B1 Accept
=09    Button B2 Cancel
=09    End
=09</verb></tscreen>
---end of quote

In my opinion it would be good to modularize the conf program into
ressources. These ressources are CFG servers.
So configuration would be a process of getting instructions from the
client above and internally have some definitions (CFG scripts) which
result in actions. The server can become itself a client "calling"
other ressources (or operating directly on sys ressources like conf
files, tools, etc.). So remote admin and OS specific conf would become
more easy I hope. And without reprogramming the user can run a
conf/admin automat (script or so) or a GUI on any ressource.
There would be a daemon lib which is a sort of CFG parser.
But many daemon process instances would probably slow down the
system, or?

(The UI itself could be client to the UI and client to the
resssources: UI display server<---UI program--->conf ressource server
Maybe reusing the UI server of linuxconf is an option.
It's sort of alpha stage but will soon support console with newt,
X and HTML and will support helptexts.)

Linuxconf folks intentionally did not modularize as radically as I
suggested above. They have a core and some outsourced modules.

Someone mentioned already both ideas (a core "center" and everything
being a module) on this list I think.

I think that the design currently discussed in the other thread
"J&J reinvent the wheel: they rediscover db & oop :)",
has strong influence on the issue which UI interface is used.

Kind regards
Peter Wiehe