MIR stands for Model vIew aRchitecture. Originally, Smalltalk used a design pattern named Model View Controller (MVC), that is often used when building user interfaces. In Design Patterns, Gamma et al. write:
MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input.
When the Controller and the View are combined, the result is the model/view architecture. To have a better idea of this approach we can think about the current WWW model. The view is the HTML code rendered by the browser, and the model is the set of CGI scripts (PHP, Perl, etc.) that run in the server whenever a "high level action" is done by the user. By "high level action" we denote complex actions like sending all the data (of a form) to the server. There are multiple simple actions like the mouse events, keyboard inputs, interactions between the widgets, etc. from which the model is not aware.
The big advantage of a model/view architecture is to decouple data from view and user interaction. For instance, a tree data structure can be represented as a menu (menu-view), as a tree (tree-view), as a toolbar with menus (toolbar-menu-view), etc. The different view-elements (widgets) can be pre-set or decided on the fly depending on either the display restrictions (ex. screen space) or user restrictions (ex. accessibility). Also the views are in charge of the interaction with the user, which drive us to the concept of a framework.
A MIR-Framework is a set of widgets and rules that govern (manage the input events) a view. A very simple example would be a normal PC framework that will show something like the current Windows, MacOS, KDE, Gnome, in contrast to the mobile framework, that will adapt a program view to a mobile device (read PDA or intelligent phones).
Said this, we can offer different views and view-elements based on the Framework we are using. How many times have you desired to have a more naive or easy-to-use interface for your preferred office document writer? (naive/normal/expert user interfaces). Have you ever desired to have a very simple mobile phone that only send/receive calls and SMS? (for young childs or elder persons, for example). Do you need to modify your program due the accessibility of the user? (offer check-boxes instead of a combo-box for example)
MIRS is the implementation of the MIR model. It is basically a widget plus a layout render engine. The product of the engine must be rendered by some graphical library. Currently this mission has been delegated to Cairo due to the output facilities. For instance, taking an screenshot of a view will be as easy as render it for the Cairo-backend surface of the desired graphical format.
The input of MIRS are (1) the interactions of the user when using the input devices and, (2) the views. These interactions (coming from mouse, keyboard, touch-pad, touch-screen, timer, etc.) are mapped into events that will be processed by widget automata, optionally producing new events. After the automata phase has elapsed, the new changes are sent to the layout engine, which can produce more events or render the result. The set of widgets that MIRS will create are specified by a view.
MIRS is an event oriented program, which means that it is not actively reading from any input device, but from an event list. Several OS-dependent agents are responsible of reading from input devices and queue events into the MIRS. Notice that the timer is also considered an input device. This made possible MIRS to be integrated in some environments like games, in which the events are obtained from the game engine, which might directly manage the input devices. Have you ever tried to click a button with a joystick?
A view can be read from two different sources: a socket and a file. The content of a view looks similar to an XML-like document, and it contains information about how to map a data-variable from the model to a widget and how to arrange the widgets. Additionally, it can also contains information about widget managing, that is, when this button is clicked that dialog-box appears.
Depending on the backend used in Cairo, MIRS can run on several architectures. For example it is possible to run MIRS on windows or on X-Server. In such a case, a new window will appear and inside that window MIRS will render the view (like GTK, Java or Qt does). The events received from the host window will be sent to the MIRS engine which will run all the necessary machinery.
MIRSX is a total orthogonal project to MIRS, that consists in developing a backend that will allow MIRS to run as standalone (ala X-Windows server). Several agents will be started to inject events into MIRS. Most of these agents are drivers, but others like a "modified file" or the "timer" are not.
Nowadays, there is a tendency to think about cloud computing. That is, to execute a remote application in the local machine storing data in the remote machine. The current HTML language does not offer the necessary richness to accomplish this. First of all, there is not link between the server-side running program and the client-side user view. Therefore, the client view must store the necessary data to provide the server-side process enough information to recover from its last execution. Lately, web developers are doing extend use of JavaScript to develop rich applications that look similar to desktop one and do only communicate with the server whenever it is needed. Cases like Gmail or online "office packages" (Google docs, Zoho) are good example of this.
MIRS-Gate is the gate of MIRS to internet. Although it is still in design phase, it looks very promising. The basic idea consists in downloading the view via HTTP, in the same way that a browser will do. A static connection will be stablished with the model. To avoid overflow in the number of connections, several connections would be multiplexed and the state of the model program could be stored in a cache, in order to have few instances of the model running in the server. The main goal of this approach is not to challenge HTML-Ajax model, but offer new solutions to another problem: execute your application in as many ways and environments as possible.
Let us put all this information in a more useful way. You access to your web-application, for example, your email reader, and you play with it as you would do with any normal current web-application. Additionally, now, you can download a "dumb-model". This model will allow you to execute your online-application being offline (this is possible because you only have to save the data that you will send to server). Of course the functionality could be limited to those tasks that do not require answer from the model (server). Yeah!, you will not be able to read your emails in offline mode!, but you will be able to compose, delete and rearrange them. When connecting to internet, an synchronization of the data of the program will be done. This can be seen as a typical control version programs like CVS, SVN, GIT, Hg, etc. when you do a commit of your program code.
Now, you, as a developer, take this model with probably the same view (footnote: there are no limitations to the internet view, as the framework stored in the client side is the same than the one used when executing the application in local mode) and make a nice installer for your host OS. MIRS will execute your program saving the data in your hard-disk instead of on the server (did you notice that both use sockets?).