IPC (interprocess communications)

7.1: adda/co/IPC (interprocess communications):
intro:
. the mvc pattern means that
programs don't use a gui directly;
rather, programs are designed to be
used by other programs,
and if a human user needs access to a program
then we pair it with a gui-producing agent
-- that's the controller in my definition of
mvc's model-view-controller .

. keeping the mvc pattern in mind,
the parts we see from the gui
are the program's exported obj's
or the content of IPC* channels .
*: (IPC: interprocess communications).

. just as human users of a program have a
view window for seeing an exported obj's state,
programs as users of other programs
have a view that consists of a buffer,
like what is offered by a file server
(rather than loading the whole file in memory,
it places the first unread chunk into a buffer)
. what buffers have in common with
user view windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).

. while subprograms typically communicate with
one or more out-mode params
(including the return value
which is actually an implicit out-mode param),
subprocesses communicate via IPC channels,
which are generally equivalent to
gui windows and menu systems
that are being used by a program instead of a human .

views:
. each process can see its channels in a list;
and, just like the file browser's detail view
is showing the attributes of files,
attributes of a channel include:
content type, obj size,
buffer size, buffer's current location,
and process being communicated with .
. such a list of channels is a matrix:
channels are the rows,
and attributes are the columns . [8.8:
. in addition to showing a process's channels,
we might also want to see the system's channels:
the columns of that matrix would include
all the processes a channel could be connecting;
and, the matrix cells would indicate the mode:
does a process just read from the channel,
or also write to it? ]

compared to parameter modes:
. just as parameters can have modes {in, out, inout},
channels can be {readonly,  writeonly, read&write}.
. if both ends can read&write to the channel,
which one is the {importer, exporter}?
importers have access to menus and dialogs,
exporters have access call entry queues
which are storing the service requests
that resulted from clients' menu selections
(these requests include any records
that have been generated by dialogs).

. in order to have channel users being equals,
instead of having a client-server relationship,
they should both be importing the same channel
from a 3rd-party server .