[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Last call for 'This Year ...'

From: Stephen Compall
Subject: Re: [DotGNU]Last call for 'This Year ...'
Date: Sun, 29 Dec 2002 17:29:00 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021217

Hash: SHA1

Peter Minten wrote:
> * SEE

Here you go.  And a Developer Testimonial for myself is at the bottom.

- --
Stephen Compall - Also known as S11001001
DotGNU `Contributor' --
Jabber ID: address@hidden

The principle of capitalism is the idea that people manage to make
money by producing things and thereby are encouraged to do what is
useful, automatically, so to speak. But that doesn't work when it
comes to owning knowledge. They are encouraged to do not really what's
useful, and what really is useful is not encouraged.
        -- RMS, Byte interview, 1986

Version: GnuPG v1.2.1 (GNU/Linux)

*                                                                    *
*                     Secure Execution Environment                   *
*                                                                    *
*                         by Stephen Compall                         *
*                                                                    *

The "Network SEE" project, code-named `antares', provides a stable,
multi-user, cross-platform, cross-language, multi-Virtual Machine,
minimally configured environment for writing responsive, trusted
network applications that can cooperate with each other over multiple
network transports chosen by their users.

That was a mouthful!  The antares source tree has existed since June
2002; however, real work didn't start until the beginning of October,
when a new architecture description was written, Network SEE v2 [1].
Now, antares has a home in Savannah CVS [2], and developers are
looking at how various aspects of the SEE can be combined with VRS in
a common codebase, the DGEE.

Now that I've used all those buzzwords, I'll note why I think they

stable: Does a stable kernel crash when it runs out of memory?  No,
but many applications considered stable choose to do so when they run
out of memory.  This is unacceptable for the SEE.

SEE uses a multiprocess model with IPC between the various aspects of
its operation.  When one dies, it doesn't take down the entire system,
and can be restarted by a guardian.  Also, each network service runs
in a separate process (though not each connection), further preventing
a service from harming the SEE or fellow services.  This is necessary
for multiple users....

Finally, the SEE doesn't try to do anything that would be better done
elsewhere, such as sandboxing services.  That's better done by the

multi-user: We're not about to extend the old "God, root, what's the
difference?" adage.  Users can add their own services and network
transports.  These are run at the users' privileges, of course,
another benefit of the multi-process model.  Addition and removal can
be done at runtime.

cross-platform: The system is targeted at GNU systems primarily, with
BSD and MSWindows following.  The codebase is designed with an aim at
adding more generally useful platform-dependent code to the GNU Common
C++ library. [3]

cross-language, multi-Virtual Machine: As VMs run in separate
processes, no common extension API need be adhered to; the VM
interaction runs only as far as OS-level VM startup.  Provided that
the language and/or VM, or libraries, provide the basic facilities
(such as I/O and XML support) needed for SEE interaction, the service
can handle what is necessary.

minimally configured: Instead of name=val configuration files, we use
"config trees" that can be managed from your preferred file and
directory editor.  The presence of a service executable file in the
right place provides all the information SEE needs to run it.

responsive: As the service guardian allows a single service process to
manage multiple requests at once, a simple responsiveness test can
tell the guardian whether or not it needs to start up another copy to
share the load.

trusted: Besides the sandboxing capabilities of VMs, the SEE also
contains a Virtual Identities system to identify the creator of a
service and to allow automated or manual decisions on whether software
is "trustworthy".

network applications: SEE supports client/server and P2P network
models.  It can also manage installation of services and clients,
making even first-time service as easy as visiting a web site.

multiple network transports: The simple generalization we get from
pushing network transports into separate processes gives us great
power.  Services and clients don't have to know what transport they
operate over; thus, the SEEs and users can choose.  New transports can
be added and removed at runtime, so it is possible for a service to
one day operate over a transport that didn't even exist at the time of
its writing.

cooperative: The main defining difference between webservices and
network applications in general (for me) is that webservices cooperate
over a single network transport, whereas traditional network apps each
must stake out their own territory (i.e., a network port number).

[1] Network SEE architecture v2 was greatly inspired by my readings of
GNU Hurd architecture documents at the time, particularly the benefits
brought about by running the kernel as separate aspects in user-space,
increasing stability and allowing users to add their own kernel
modules without root access.  See for the latest

[2] CVSROOT=:pserver:address@hidden:/cvsroot/dotgnu-see,
module antares.  Project page is


Testimonial for Stephen Compall:

I find that the development environments available today are
inadequate.  It's too hard to write portable applications.  It's too
hard to write stable network services.  It's too hard to distribute
your software in an easy-to-run format.  I came here to help build
what's been called for by Barry Fitzgerald: the Best Dam*ed
Development Environment Ever.  And I hope, in some small way, I can
help do that.

Version: GnuPG v1.2.1 (GNU/Linux)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]