Re: [DotGNU]SEE - what's the point?

[Norbert Bollow]

S11001001 <address@hidden> wrote:

> -Is Andromeda just a proof-of-concept,

Consider it "just proof-of-concept"... the code has been sitting there
so long without anyone working on it... it's certainly justifiable to
start orver from scratch if that is what you want to do.

> - Can SEE and DEE really be separated?  It doesn't look like there's
>   much for the SEE to do, other than distributed execution
>   (multi-platform, maybe even multi-plugin...)

Yes, the SEE daemon is supposed to be simple.  Most of the complexity
goes into the VM plugins, the auth system (an auth library should
probably be linked into the daemon) and a separate library that
enforces a common set of security policies across all VM's (this will
be made accessible to all the VMs through VM-specific glue code; the
daemon itself won't be involved in enforcing security policies after
the code has been passed to a VM for execution).

The DEE on the other hand will be a complicated thing consisting of
multiple SEEs (that will typically run on different machines) which
provides the end user with functionality similar to a SEE with the
difference that everything should still work if one of the servers
breaks down.  (Think "Redundant Array of Inexpensive Servers").

Maybe we should first build the SEE and get it to the point where
it can be used for something useful, and only then start worrying
about the details of the DEE.

> If pnet runs on its own, then what do we need SEE for anyway? Specifically, 
> s'il vous plait. And I've already read enough of the stuff about providing a 
> framework, pluggable interface, but /what does the code do?????/

The SEE daemon should probably be little more than a slightly fancy
inetd which is capable of handling three types of requests

 (a) user connects to run a program on the server
 (b) user connects to download a program to their machine
 (c) server connects to run a program on the user's machine

and which does the following:

1. Examine a "portable executable" and determine what VM is suitable for
   this.

2. Call the auth system which determines whether it's ok to run this
   code.

3. Depending on some configuration file, determine whether an alarm
   should be raised or not.  Raise the alarm if necessary.

4. If the auth system said that it's ok to run this code, fork-exec
   the appropriate VM.  Otherwise print an error message and close
   the connection.

Greetings, Norbert.

-- 
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month  http://cisto.com