nanogui: make microwin api : client/server
Subject:
RE: make microwin api : client/server
From:
"Rob Taylor" ####@####.####
Date:
27 Apr 2000 15:06:28 -0000
Message-Id: <001901bfb058$e9d711e0$b400a8c0@eventhorizon>
sorry, I just re-read this and could help but comment some more ;)
>
> > I don't want Palm OS, and I don't want Windows 3.11. Surely everyone
> > could understand why. In the same breath... I don't want X. Something
> > in between, something standard based, and something simple. If
> > someone had experience with other graphics display engines, they
> > should be able to read a PDF for a day, and get the hang of what we're
> > doing. I don't think that's feasible now...,
have you ever read the Xlib manual or the X server docs? I'll tell you this
now: to understand (I mean really understand) how X works is no mean feat.
To program an application to run in X is however pretty simple, and people
get the hang of it every day.
As far as Microwindows is concerned, to write a program to run in it you
simply read some standard win32 developers docs, include the right headers,
link appropriately, and things work (or at least, they will). For nano-X you
read nanox.h and similarly it's all pretty straightforward. Your average
application programmer doesn't need (and indeed want) to understand how the
whole kit and kaboodle works, down to the very last jot, they're just
concerned that it works, and works well!
>but how could it be made
> > that way? You can't have an application copying to the framebuffer...
> > that's insane. Where's the separation between server and app?
there isn't one. in fact I'm not even proposing a client-server system - not
everything needs to be client-server. One of the biggest myths in computer
science is that client-server is the be-all and end-all in multiprocess
design. it isn't. sometimes its a good system to use and sometimes it's the
worst. To restate the nature of the problem: there are a number of processes
accessing a resource. you need controls on how they access that resource.
There is no absolute need of a server process as the gateway to that
resource, that is simply one solution to the problem.
Just cos everyone does something the same wasy, doesn't mean it's the best.
for local graphic rendering, client server is definitely not the best
paradigm (X was designed for network use.)
> Just say: put this on
> the screen, and a reference to some data (pointer), then the API would
> say... do we have SMT, okay good... let me copy this stuff over and
> notify the engine that it's supposed to put this on the framebuffer
> at these "relative" cooridinates to our window. Oh, no SMT?, okay let
> me contact the socket and write them synchronously, or asynchronously.
I think you're getting a little confused - whatever scheme is used, all the
application programmer will say is 'put this on screen', how the library
does that is up to us, now. the logic of who accesses what being done in the
lib aint that much different to the logic being done in the server, unless
you're really bothered about the security of the device that your
controlling access to: as the device were talking about is the framebuffer,
I don't think it warrants these degrees of security concerns.
Rob
p.s. shaun - I don't seem to be able to get emails to your isupportlive.com
address. I get
####@####.####
all relevant MX records point to non-existent hosts:
it appears that the DNS operator for this domain has installed an
invalid MX record with an IP address instead of a domain name on the right
hand side
