[cap-talk] Evlan presentation slides

[Ian G]

Hi Kenton,

I have no idea whether the following comments are
relevant, but here goes...

Kenton Varda wrote:
> As far as I/O goes, when Evlan restores from a snapshot, it simply 
> treats all open network connections as if they had been reset.

Shades of "Reliable Connections are Not" :-)
http://iang.org/ssl/reliable_connections_are_not.html

> Currently the only large application written in Evlan is a web server, 
> and for a web server this strategy works fine, since it expects 
> connections to be flakey and mostly stateless.  But, clearly the problem 
> will be more complicated for other kinds of software.  I haven't thought 
> much about this yet.  Thanks for sharing your thoughts on the subject.


A connection that is stateless is just a complicated
packet delivery mechanism.  Things get a lot easier
when you remove the connection paradigm from all
systems and layers, then -- I find -- the architecture
eventually settles down to a three layer style:

      Decision engine - application.

      State Machine - persistant storage

      Packet delivery - datagrams

The trick is to ruthlessly move the reliability up
to the highest layer (including to the user if poss.).
That is, strip out anything that might be considered
to be "connection oriented" from below layers 1..n-1,
every message is throwaway below the top layer.

When it works, the results are quite nice; I generally
see a 2 times speed up in performance, and an overall
increase in reliability.  (But I have only 2-3 cases
so it is no scientific measurement.)

The bear of it all is that you end up having to rewrite
large chunks of code.

>     On the topic of "No filesystem" - I wonder why that?
> 
> 
> Clearly everyone needs a way to organize their stuff.  But, in an 
> entirely Evlan world, filesystems would be implemented as user 
> applications, not a core component of the OS.  It would be really easy 
> to write an application which acts as some kind of container for 
> arbitrary objects/capabilities.


One of the difficulties of server software is that over
time, the idea of "file system" as a reliable storage place
has diminished.  For example, you'll find most software
out there has replaced the file system with relational
databases, and things like J2EE go so far as to try and
stop you using the file system.

iang