[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Re: [DotGNU]The DotGNU System
From: |
Chris Smith |
Subject: |
[Vrs-development] Re: [DotGNU]The DotGNU System |
Date: |
Sun, 27 Oct 2002 00:13:02 +0100 |
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
- [Vrs-development] Re: [DotGNU]The DotGNU System,
Chris Smith <=