[Vrs-development] Re: [DotGNU]The DotGNU System

[Chris Smith]

On Saturday 26 October 2002 15:19, Peter Minten wrote:
> 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:

Hey!  Your diagram is better than mine! :o)

> 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).

These additional elements are exactly the type of 'extension module' I 
refered to in my DGEE page.

The whole architecture is designed to be very modular to support this.... now 
I just need to find s M$ conversent developer to help port the middleware so 
it'll run on MS as well as Un*x...  

Any takers?


> On the client side there is only a VM. 

Not sure what you mean by this.  You're saying that a pure client-only 
execution environment doesn't have the auhtorizer etc?  I'd subscribe to 
that, however I'm not sure what makes a 'client' installation different from 
a 'server' installation right now, other than dissabled components.  I 
propose worrying about this later when we've got something running.

> 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).

Yep, I go with that.  However the protocol must be invisible outside the 
Network Server as it will be the only way to guarantee inter-operablity and 
extensibility. Data encoding however is visible... if the request came vi 
XML-RPC over HTTP or Jabber, we've still got XML at the end of it.  The web 
service has to know how to deal with XML.

As for the Butler itself, I have considered using a sandboxed filesystem with 
the VM (chrooted, ulimit tied etc) to prevent system compromise (in fact the 
VRS is supposed to have a 'virtual' filesystem... though this is going to be 
very, very tricky).

How you 'sandbox' other resources (like mysql and system resources) is 
another thing altogether.


> 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 :-).

This will always be a problem with users systems when downloading 
applications.


> Greetings,
>
> Peter

Cheers
Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk