model-view and composite tech

[thought I blogged this 9.2, but found as draft;
then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:

"( Potel questioned the need for the MVC's Controller;
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.).

. after reading that, I wrote this:

. I didn't get mvc either, and promptly redefined it:
subrograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .]

one call for trees of operations

7.22: addm/one call for trees of operations:

. the key to efficiency will be
providing support for integrated use of
both oop and concrete types;
ie, if the tree needs to be done fast
or in a tight space,
then the compiler uses native types;
but if it needs to handle polymorphism,
then it uses the type-tags,
and sends it to an oop type .

biop* oop:
*: (binary operations)
. the problem with the popular oop model
is that it is not helping much for biop's;
so, we should consider the binary parameter
to be one obj;
and, we again have oop working .
[8.13:
. this has always been implicit in my design;
biop oop works by featuring
2 type tags per arg: (supertype, subtype);
eg, (number, integer);
and then we don't have to worry about
where to send a (float, integer)
because they both have
the same supertype: number .
. this note was just pointing out
that I was realizing the syntax x`f -- vs f(x) --
was ok; whereas, previously
I had howled that oop was absurd because
it turned (x * y) into x`*(y)
as shorthand for asking x's type mgt
to apply the *-operation to (x,y);
what oop needs to be doing is (x,y)`*
as a shorthand for calling the type mgt that is
the nearest supertype shared by both x and y,
and asking it to apply the *-operation to (x,y).
8.15: and of coure,
oop langs like c++ need to get their own lang
and stop trying to fit within C,
so then we can go back to (x*y)
as a way to write (x,y)`* .]

signals

7.27: adda/cstr/signals:
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .

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 .

gui notification systems

6.4: adda/gui notification systems:

[. the original version of the gui pointer,
is a sort of additional type:
x.gui.t -- x is a gui pointer to type t .
. that way, you could pass x around,
and all type mgts then know
that in addition to performing the requested operation,
they should also be notifying the gui system
if the operation entailed a modification .
. the point is to be like QT's signaling system:
what is special about a gui'd obj
is that any modification triggers a signal to the
notification center,
which keeps a list of things to do in response .
. my revision of QT's idea was to
make gui notification a special case
so that instead of giving every object
the ability to emit notifications,
we are establishing a relationship directly with gui mgt
rather than going through a notification system .
. the gui type is an obj header that all type mgt's understand,
and it has any additional info that might be needed
in order to identify an object to the gui system .
. the type mgt needs to know
what operations can cause modifications
or it needs to compare before&after values
if any of it's outputable's are gui typed .
. not sure I was thinking of all that when I
designed the following ...]

. seems like the simplest gui system is to have
a gui ptr for each window you intend to export,
then the gui system knows to follow this pointer
and print whatever happens to be there .
. that way you don't have to decide at design time
what will be displayed .

[. to provide this feature of dynamism
combined with a gui system notfication service,
you simply mov from (x.gui.t) to (x.t; p.gui`= x)
and the system understands gui.types like p to be
dynamically type-tagged . ]

. if repointing the gui ptr dynamically,
and if we are translating adda to c,
then how is switching the gui ptr translated
into dynamically created gui views?
. our c datastructures must include type-tags;
if the type doesn't come with a type tag,
then the compiler has to do the boxing
(this is possible because
all symbols refering to untagged obj's
must be statically typed ).

. this complicates efficiency because
if the gui ptr can be dynamically changed,
then anything it might be repointed to
will have to be fully boxed (have type-tags included).
[. and obj's that are statically typed,
cannot be type-tagged;
so how are we getting notifications to happen?
. the compiler needs to know what will be gui'd;
if we want to do that dynamically,
then we'll need to compile dynamically
(eg, that means compiling to addm or python
instead of to a native lang like c or obj'c ).
. once the compiler knows what's getting gui'd,
then it knows when gui'd obj's are being assigned to
statically typed out.mode parameters
and it can notify gui mgt
after that parameter's procedure is done operating .]

6.30: needs a type-tag:
. gui-notify (is-mirrored) is like read-only subtype;
if modified {is-rom: raise error, is-mirrored: notify gui}
maybe there needs to be some additional implicit params
that provide bits for every subtype:
esp'ly is-rom, and is-mirrored?
. obj's don't need a read-only bit because
that is part of static typing,
but is-mirrored is a dynamic subtype
since we want the run-time to control what's mirrored and when;
thus any obj's that can be mirrored
will needs polymorph typetag indicating whether
gui needs to be notified when obj may have been modified .

6.30: keeping the mvc pattern in mind:

. the mvc pattern means that
programs don't use a gui directly,
they 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 .
. keeping the mvc pattern in mind,
the parts we've referred to as being "(gui'd)
are generally known as the exported obj's
or the content of ipc* channels
*: (ipc: interprocess communications).

. just as human users have a window into an export,
other controllers have 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 windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).

7.1: how is an obj's mirrors identified?:

. if we allow the mem system to be virtualized,
then when c provides the address of an obj,
we can no longer use that as an obj id,
because pages (and their obj's) are sharing physical addresses;
therefore, we need some way to identify obj's
in order for the notification system to work
(once some type mgt finds modifications require notification
the notification system needs to know
which obj in which channel needs to be updated;
so, it either has to map an obj id to these things,
or it needs to include with each mirrored obj
a notification id).
. if the notification bit were an entire word
then not only is this easy to read,
but also non-zero values can serve as notification id's .
. however, the whole point of it being a bit
is that this is something that has to happen to every obj type
(is this a mirrored subtype or not?)
so it should to be very space-efficient .
. if it's found to need notification,
then how is the system managing obj identity ?
is it the c-detectable address of the obj? .

addx guarding

6.26: addx/IPC monitoring:
. how to assure that IPC ability is fair?
need to keep a rough count of each process's
use of message-sends,
if things are getting bogged down,
and someone is out-mailing a lot,
then need to alert user to the app
for ideas about why that app might need to out-mail so much .

6.29: addx/malloc/privacy assurance:
. when doing mem alloc,
privacy could be done with minimal erasing
if each sensitive domain
did its own recycling .
. also if the next domain is trusted (the os)
then erasing would not be needed,
suggesting that erasure not be done until
the block is reallocated .
. on most practical systems though,
addx will be a system on an untrusted system,
so then you'd need to erase as soon as possible,
and still not be sure of privacy!

battery-saving architecture

3.27: addx/batt'saving architecture:

notifications:
. without notification systems or hardware interrupts
ipc (interprocess communication) requires
a polling loop which uses power all the time
just checking for whether anything needs power!
. notifications work by having service agents
tell the os what they are checking for,
and then the os will call them back when it happens .

power-saving mode:
. another needed control system is batt'savings mode;
because, agents can provide
higher levels of service if they know
whether the user has nearby access to more batt's .

. services can vary their levels of service by
putting optional services in a separate thread,
and then marking that thread as optional
which then affects its scheduling priority .
. the user can indicate how much to conserve,
and then the system sets a power.conserve.flag .
. the scheduler can use that flag
to adjust the way it schedules the optionals .

. put all optional work on a todo,
else if it's now-or-never,
tell the user what's not being done
while on min drain mode .
. another option while employing a user agent
is letting the agent handle the annoying,
repetitive questions from a service .

. the os uses the average recent rates of cpu useage
to estimate relative batt'life or work levels .
. the os also considers batt's charge age:
if the batt' is near the end of life,
then optional services should be cut anyway
since being in that state worsens the amount of
batt'drain per work done .

. if the system is working more than minimally,
it can then ask the user
whether they'd rather have more batt'life .
. it could do this with an alert
or an on-going notification (animated icons)
for both work intensity and remaining energy;
but, on some systems,
the remaining energy is not easy to measure .