nanogui: Thread: Proposed "new" source tree

We'll still have to await the final outcome of the discussion with Greg
Haerr and Alex, but here's a proposal for a unified source tree. There
are still certain things which I don't understand in the current nanoGUI
source tree, which need revisions.


1. The Server
At the core of everything is a server, which is either embedded with the
client or acts as a network server to a Unix domain socket or a TCP/IP
connection (or even a NetBEUI or IPX connection.) It multiplexes through
the client connections, processing client calls, and processes data from
the devices and generates events.

2. The Device Thingie
The device thingie implements various devices, currently screens,
keyboards and mice. It communicates with the server. The device thingie
has to be on the same machine as the server.

3. The Core Library
The core library (nearly analogous to lib/client.c) implements the
server communications protocol. It is either embedded with the server,
or communicates with the server through Unix domain or
TCP/UDP/NetBEUI/IPX/whatever connections.

4. The Personality
A personality is an interface to the core library. A personality may or
may not implement the entire protocol. Personalities would include a
"native" personality, an Xlib-like personality, Win32, EPOC32, PalmOS,
EPOC16, Gdk, or whatever.



I wouldn't mind beginning work on this. 


/
	/server
	/lib
	/demos
	/personalities
		/nanolib
		/nanoX
		/nanoWin32
		/nanoEPOC
		/nanoPalm
		/nanoGdk

-- 
Check out www.windows2000test.com, a test server of Windows 2000 set up
by Microsoft. By the way, it has been down a couple of dozen times and
cracked once.

On Thu, 9 Sep 1999, Guan Yang wrote:
> 1. The Server
> At the core of everything is a server, which is either embedded with the
> client or acts as a network server to a Unix domain socket or a TCP/IP
> connection (or even a NetBEUI or IPX connection.) It multiplexes through
> the client connections, processing client calls, and processes data from
> the devices and generates events.

Most likely we won't add support for any kind of networking other than
Unix domain sockets unless someone really wants it (and then it'll
obviously be a config option). Adding support for accessing remote
machines will have a lot of security implications, for one thing.

> 2. The Device Thingie
> The device thingie implements various devices, currently screens,
> keyboards and mice. It communicates with the server. The device thingie
> has to be on the same machine as the server.

That's part of the server itself. There's no point making it seperate from
the server in any sense other than that there is a set API within the
server which can talk to "a keyboard driver" or "a mouse driver" rather
than "a hardware PS2 keyboard driver" or "a linux console keyboard driver"
or whatever.

> 4. The Personality
> A personality is an interface to the core library. A personality may or
> may not implement the entire protocol. Personalities would include a
> "native" personality, an Xlib-like personality, Win32, EPOC32, PalmOS,
> EPOC16, Gdk, or whatever.

I was thinking more of alternate client libs rather than yet another
layer which sits on top of the normal client library.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Friday, September 10, 1999 2:48 AM, Alex Holden ####@####.#### wrote:
: On Thu, 9 Sep 1999, Guan Yang wrote:
: > 1. The Server

	I agree with Alex on his points about device drivers and personalities.
On the networking aspects, yes, we've started with UNIX domain sockets, but
it might be nice to have a connection or connection-less oriented protocol-independent
paradigm.  In this way, the network connectivity side of the server could be
replaced by just rewriting a few routines...  (perhaps yet another "driver" interface
here is warranted)

Greg


: > At the core of everything is a server, which is either embedded with the
: > client or acts as a network server to a Unix domain socket or a TCP/IP
: > connection (or even a NetBEUI or IPX connection.) It multiplexes through
: > the client connections, processing client calls, and processes data from
: > the devices and generates events.
: 
: Most likely we won't add support for any kind of networking other than
: Unix domain sockets unless someone really wants it (and then it'll
: obviously be a config option). Adding support for accessing remote
: machines will have a lot of security implications, for one thing.
: 
: > 2. The Device Thingie
: > The device thingie implements various devices, currently screens,
: > keyboards and mice. It communicates with the server. The device thingie
: > has to be on the same machine as the server.
: 
: That's part of the server itself. There's no point making it seperate from
: the server in any sense other than that there is a set API within the
: server which can talk to "a keyboard driver" or "a mouse driver" rather
: than "a hardware PS2 keyboard driver" or "a linux console keyboard driver"
: or whatever.
: 
: > 4. The Personality
: > A personality is an interface to the core library. A personality may or
: > may not implement the entire protocol. Personalities would include a
: > "native" personality, an Xlib-like personality, Win32, EPOC32, PalmOS,
: > EPOC16, Gdk, or whatever.
: 
: I was thinking more of alternate client libs rather than yet another
: layer which sits on top of the normal client library.
: