mvc with client-server architecture

6.20: addx/mvc with client-server architecture:

. strict mvc means model lets
controller do the image writing to screen .
. if part of the model includes
generating images,
then these can be composited
by the controller
to wherever the chosen view is .

. the x server allows remote servers
to be treated similar to local servers .
. the addx server model is not
concerned with such networking;
the main point is mvc modularity:
. the servers providing an mvc`model
need to be working for mvc`controllers
not for the human users directly .
. the model can then be used either by
human views or robotic views;
most typically, the point is to provide
more choice for the human
by letting a robot filter what the
model is intending for the human,
similar to the way bodyguards work .
[6.26:
. this isn't meant to escape from
contracts like google's
where the ad's must be human-visible
and the inquiries human-initiated;
it simply means that all models
are capable of robot accessability .
. one way this can help while
fulfilling the google contract
is to have the robot help with
making wise keyword choices:
it presents a list of suggestions
and the human can merely press enter .
. robots can also be reading along
to help humans spot the best leads .
]
. in addition to that mvc architecture,
the model may want to divide itself
into server and client parts
in order to efficiently modify the model
from afar .
[my intuitive assumption:]
. the x window system works on the idea that
it would be most efficient if
the os could provide a generic client part
that many servers could use,
since servers often need to make similar moves .

api:
. don't I need to have a
carefully selected set of api's
in order to know how to do the
x thing (where the model has
separate server and client parts) ?
. one could take it
one example at a time:
cloud computing depends heavily on x:
. some things like controlling the cursor
can't be done quickly eno' by remote .
. if the model does some
major modifications
the data needs to be with the server;
that's where it originates from,
so no problem .
. letting the user quickly scan
large portions of data
means that the data should be
mirrored there too
unless the platform is tiny .

review of higher view:
. mvc works naturally with x,
since the Server = Model
and the Controller along with its
choice of View = Client .
. the View consists of
the Controllers way of arranging
the data in a form that is
optimal for viewing .
. remote does complicate things a bit:
the non-remote controller has
instant access to the model,
but now with the model so far away,
the controller is having to think about
how much to ask for in advance
depending on the size of the local system .


6.26: addx/x protocol/server client terminology:

The term server and client have different meanings.
XServer runs on your graphically rich desktop
(it serves up the view)
X11-client (like app is client of OS)
may run anywhere on the connected network

lwn.net:

The program which provides access to
system resources (display, keyboard, mouse)
is the server.
The shorter-lived applications
which connect to the server
to make use of these shared resources
are the clients.
This is perfectly consistent with
every other use of "(client/server) .
What throws people is that
we're used to thinking of servers as
a particular type of *hardware*,
steadily ticking away the CPU-hours
in some climate-controlled back room,
out of sight, whereas "clients"
are the visible workstation PCs
at everyone's desk.
However, the X client/server terminology
is perfectly reasonable
from a *software* point-of-view,
and X is software, not hardware.