[DotGNU]The DotGNU System

[Peter Minten]

Hi folks,

thanks to the folks from Architecture The DotGNU System is finally becoming
somewhat visible. From what I understand the system looks somewhat like this:

 1            A                          B                          C
--> +--------------------+  2  +-------------------+  3  +--------------------+
    |   Network Server   | --> |  Service Manager  | <-> |  Resource Manager  |
<-- +--------------------+     +-------------------+     +--------------------+
 8            ^                      |     5                        ^
            7 |     /--------------- | -----------------------------/
              |     V                |        
    +--------------------+     4     |                   +--------------------+
    |   Virtual Machine  |<----------/                   |     Authorizer     |
    +--------------------+                               +--------------------+
        ^   D   6   ^                                           ^   E   ^
    9   |           |                    8                      |       |  10
<-------/           \-------------------------------------------/       \----->

This is based on the DGEE page Chris Smith has put up on
http://www.nfluid.com/dgee/dgee.html but has some extra elements. The extra 
elements are:

E   --   The Authorizer. This is essentially the Auth system of the server 
         (I understand that both VRS and SEE have an Authorizer build in).

8   --   Communication between the VM and the Authorizer. This is the question:
         who is this user?

9   --   Communication between the VM and the outside world. This is mainly the
         communication with other webservices. On the client side no extra
         stuff is needed and thus the communication does not go through the
         Network Server.

10  --   The communication between the Authorizer and the outside world. This 
         represents the talking of the Auth system on the server with the auth 
         system of the user (that doesn't need to be on the users machine).

On the client side there is only a VM. In this VM there are libraries that can
be controlled by the webservice. One example is a GUI toolkit like QT#. The
webservice uses remoting to control the toolkit (for example to draw a box).

As a consequence a program to (un)load libraries, send through commands,
disallow naughty stuff (like 'rm -f'), etc must run on the users box. Let's call
this program the Butler :-). The Butler should be able to do the Right Thing
regardless of details like the bytecode format being executed (IL, Java or
Parrot) and the protocol being used (XML-RPC, Jabber, HTTP).

A problem may be the dependency on high level libs to be installed at the users
system. I don't consider it a really big problem, unless of course a lot of
people are going to use a lot of different UI libs in their webservices. If it
happens to becomes a big problem we can always resort to using low level API's
like XSharp and hoping that some of the high level libs will get a version that
can use the low level ones. Then the high level libs can run at the server side
and only a few low level libs are needed on the user side. You are now entering
the X zone :-).

For your enjoyment, here is the user side:

+---------------------------------+
|         Virtual Machine         |
| +-----------+     +----------+  |    
| |  UI Libs  | <-> |  Butler  | <-> {THE OUTSIDE WORLD}
| +-----------+     +----------+  |
+---------------------------------+

That's the DotGNU System. Not very complex when you look at it this way, is it?

Greetings,

Peter