[E-Lang] remote comms: Timeouts and Connection Failure

[Tyler Close]

At 01:52 PM 4/4/01 -0700, Mark S. Miller wrote:
> > At 09:37 PM 4/2/01 -0700, Dean Tribble wrote:
> > >As I recall the motivating case for breaking all the promises is amnesia.
>
>At Tuesday, April 03, 2001 2:01 AM Tyler Close wrote:
> > I am sort of reluctant to get into this, since both E and EROS believe in
> > allowing amnesia. I think supporting amnesia is ridiculous. It totally
> > undermines security and makes a mess of distributed application logic.
> >
> > As far as I know, E and EROS only have performance reasons for allowing
> > amnesia. This is a poor argument. Droplets does not suffer from amnesia and
> > does just fine on performance, despite being implemented on top of Java.
> >  From Java, it takes me approximately 20 to 40 ms to sync modified state to
> > disk. This time is dwarfed by network latency. A system implemented on top
> > of the bare hardware should be able to make the comparison even sillier.
>
>If you would open source Lock,

That's not an option. I need Lock as a commercial product. I also see no 
value proposition in open sourcing Lock.

>I would be overjoyed to stop worrying about
>amnesia, and I would be happy to specify E under amnesia-free assumptions.
>
>If not, do you know of another open source persistence solution suitable for
>E's needs, and with performance adequate for ignoring amnesia?
>
>If not, then I've got to engineer solutions that work within the constraints
>of the other solutions I can afford to engineer.  If I've got to roll my own
>persistence solution, even if I start from your Acid interface, I am not
>going to spend the level of effort needed for this level of performance.
>It's hard, and I greatly admire you for succeeding at it.  But what would
>you have me do for E?

You have plugable hardware, OS, JVM, crypto, quasi parsers and collection 
classes (if you go with Hydro). Why not plugable persistence? Your line in 
the sand about what has to be open source and what does not seems 
completely arbitrary to me. If, like EROS, E was providing software right 
down to the hardware, then I could understand, but it doesn't. The best E 
can hope for is to provide a list of "recommended configurations".

It's also worth pointing out that E on EROS would have no need for Lock. In 
fact, it seems likely that a great deal of what E currently is could better 
be provided by an OS. In the end, the only area of required compatibility 
is the language and its associated parse tree. Everything else can, and 
probably will, be replaced by different incarnations.

I don't understand what part of the E language or parse tree would be 
affected by amnesia considerations.

I'd recommend that you make a simple implementation of the Acid interface 
and implement E to the Acid interface. If/when people get serious in their 
use of E, they will either get Lock licenses, or code a better version of 
your simple implementation.

The fact that a high performance implementation of the Acid interface 
already exists should also eliminate a design burden for you. You don't 
have to worry about the performance implications of some other interface 
you might design.

Tyler