nanogui: make microwin api : client/server
Subject:
Re: make microwin api : client/server
From:
####@####.####
Date:
25 Apr 2000 10:57:11 -0000
Message-Id: <20000425034554.B4372@www.easysolutions.net>
> Anyway I think, although this is better than normal pipe transactions, I
> don't think it's the best option: you still need to marshal/unmarshal
> argumnets, which sucks. My suggestion is that the client actually does it's
> own drawing to the framebuffer, and the server processes simply deals with
> telling the client what screen regions it has use of (window
> management)(obviously with the relevent information stored in a shared
> memory buffer) and top-level event routing.
>
> What do people think?
>
> Rob
Hmm..., well..., can't only one program "own" the framebuffer at a
time? I don't know if we could segment this memory between the
various apps. I think this could be riddled with problems..., it
needs to be abstracted into a set of functions which manipulate the
memory at the server level I think. Using shared memory segments you
could for instance stick a series of bits and directly memcpy it onto
the framebuffer into the right place.... from the server side. Maybe
I'm wrong, but I'm pretty sure only one central app can control the
framebuffer memory. One potential would be to have sort of a virtual
framebuffer that apps could write that would be a shared memory page
that the server could copy to the screen. However can you hear the
slurping sound?..., yes it's your memory getting sucked up. :-).
The "best way" that I see is just to abstract the whole API. Take the
whole NanoGUI/microwin API, and let "client" apps say to the server,
perform this function on my window. Then the microwin engine says,
your windows not visible... never mind that. Only "servicing" visible
windows requests for changes. How those function calls get into the
main server app could be anything..., shmget's, et. al for local
clients, or read off a socket..., doesn't matter that much.
Of course... that's a ton of work. Seriously... a ton.
The key piece is process seperation between the server and the clients
that do the actual work. This allows more than one app to run
simultaneously... a serious short coming in our present setup. This
is present in the NanoGUI api at some level, but not Microwin. (I
mean to say the shortcoming is fully present in Microwin, but only
partially in NanoGUI)
Hmm..., this might seem a little off, but what if we were to see if
there were some really tiny CORBA/COM implementations lying around.
The server process could grab data chunks via the object request
broker, and implement them. The clients could transmit their requests
for changes to the screen to the ORB, and all would be well. This
smacks of bloat though, and that concerns me. Your right though
marshalling is non trivial. But if we leverage what someone else has
done well into our well designed setup... it could be cool. I think
in the future most modern GUI toolkits will be written like this...,
why not right the display server like this itself? (Bonobo comes to
mind)
Oh well... just a crazy idea to start your morning right.
Thanks,
Shane.
